Skip to content

Wöchentlicher PostgreSQL Newsletter - 22. Juni 2008

Der Originalartikel befindet sich unter:

== Wöchentlicher PostgreSQL Newsletter - 22. Juni 2008 ==

Neue Umfrage: Welches TODO würdest du am liebsten sehen?

== PostgreSQL Jobs im Juni ==

== PostgreSQL Lokal ==

TorontoPUGs erstes Meeting wird am 23. Juni im The Rhino stattfinden.

OKPUG's first meeting will be June 23 at 7:00pm at Coach's in
Norman,OKPUGs erstes Meeting wird am 23. Juni um 19:00 Uhr im Coach's
in Norman, OK, stattfinden.

PgDay.ITs Planungstreffen wird am Mittwoch, dem 25. Juni um 21:30 Uhr
CET im IRC stattfinden.

pgDay Portland ist am 20. Juli. genau vor der OSCON.

PGCon Brazil 2008 wird vom 26.-27. September auf dem Unicamp in
Campinas stattfinden.

PGDay.IT 2008 wird am 17. und 18. Oktober in Prato stattfinden.

== PostgreSQL in den News ==

Planet PostgreSQL:

General Bits, Archive und gelegentliche News Artikel:

Dieser wöchentliche PostgreSQL Newsletter wurde erstellt von David
Fetter und Josh Berkus.

Sende Neuigkeiten und Ankündigungen bis Sonntag, 15 Uhr Pazifischer
Zeit. Bitte sende englische Beiträge an, deutsche an, italienische an

== Angewandte Patches ==

Tom Lane committed:

- Clean up a number of bogosities around pltcl's handling of the Tcl
"result": 1. Directly reading interp->result is deprecated in Tcl
8.0 and later; you're supposed to use Tcl_GetStringResult. This
code finally broke with Tcl 8.5, because Tcl_GetVar can now have
side-effects on interp->result even though it preserves the logical
state of the result. (There's arguably a Tcl issue here, because
Tcl_GetVar could invalidate the pointer result of a just-preceding
Tcl_GetStringResult, but I doubt the Tcl guys will see it as a bug.)
2. We were being sloppy about the encoding of the result: some
places would push database-encoding data into the Tcl result, which
should not happen, and we were assuming that any error result coming
back from Tcl was in the database encoding, which is not a good
assumption. 3. There were a lot of calls of Tcl_SetResult that
uselessly specified TCL_VOLATILE for constant strings. This is only
a minor performance issue, but I fixed it in passing since I had to
look at all the calls anyway. #2 is a live bug regardless of which
Tcl version you are interested in, so back-patch even to branches
that are unlikely to be used with Tcl 8.5. I went back as far as
8.0, which is as far as the patch applied easily; 7.4 was using a
different error processing scheme that has got its own problems :-(

- In pgsql/src/backend/optimizer/plan/setrefs.c, fix the code that
adds regclass constants to a plan's list of relation OIDs that it
depends on for replan-forcing purposes. We need to consider plain
OID constants too, because eval_const_expressions folds a
RelabelType atop a Const to just a Const. This change could result
in OID values that aren't really for tables getting added to the
dependency list, but the worst-case consequence would be occasional
useless replans. Per report from Gabriele Messineo.

- Clean up some problems with redundant cross-type arithmetic
operators. Add int2-and-int8 implementations of the basic
arithmetic operators +, -, *, /. This doesn't really add any new
functionality, but it avoids "operator is not unique" failures that
formerly occurred in these cases because the parser couldn't decide
whether to promote the int2 to int4 or int8. We could alternatively
have removed the existing cross-type operators, but experimentation
shows that the cost of an additional type coercion expression node
is noticeable compared to such cheap operators; so let's not give up
any performance here. On the other hand, I removed the
int2-and-int4 modulo (%) operators since they didn't seem as
important from a performance standpoint. Per a complaint last
January from ykhuang.

- In pgsql/src/backend/storage/ipc/sinvaladt.c, remove freeBackends
counter from the sinval shared memory area. We used to use it to
help enforce superuser_reserved_backends, but since 8.1 it's just
been dead weight.

- Improve error reporting for problems in text search configuration
files by installing an error context subroutine that will provide
the file name and line number for all errors detected while reading
a config file. Some of the reader routines were already doing that
in an ad-hoc way for errors detected directly in the reader, but it
didn't help for problems detected in subroutines, such as encoding
violations. Back-patch to 8.3 because 8.3 is where people will be
trying to debug configuration files.

- In pgsql/src/backend/utils/mb/mbutils.c, fix compiler warning
introduced by recent patch. Tsk tsk.

- Fix a few places that were non-multibyte-safe in tsearch
configuration file parsing. Per bug #4253 from Giorgio Valoti.

- Rewrite the sinval messaging mechanism to reduce contention and
avoid unnecessary cache resets. The major changes are: 1. When the
queue overflows, we only issue a cache reset to the specific backend
or backends that still haven't read the oldest message, rather than
resetting everyone as in the original coding. 2. When we observe
backend(s) falling well behind, we signal SIGUSR1 to only one
backend, the one that is furthest behind and doesn't already have a
signal outstanding for it. When it finishes catching up, it will in
turn signal SIGUSR1 to the next-furthest-back guy, if there is one
that is far enough behind to justify a signal. The
PMSIGNAL_WAKEN_CHILDREN mechanism is removed. 3. We don't attempt
to clean out dead messages after every message-receipt operation;
rather, we do it on the insertion side, and only when the queue
fullness passes certain thresholds. 4. Split SInvalLock into
SInvalReadLock and SInvalWriteLock so that readers don't block
writers nor vice versa (except during the infrequent queue cleanout
operations). 5. Transfer multiple sinval messages for each
acquisition of a read or write lock.

- In pgsql/src/backend/storage/ipc/sinvaladt.c, seems I was too
optimistic in supposing that sinval's maxMsgNum could be read and
written without a lock. The value itself is atomic, sure, but on
processors with weak memory ordering it's possible for a reader to
see the value change before it sees the associated message written
into the buffer array. Fix by introducing a spinlock that's used
just to read and write maxMsgNum. (We could do this with less
overhead if we recognized a concept of "memory access barrier"; is
it worth introducing such a thing? At the moment probably not --- I
can't measure any clear slowdown from adding the spinlock, so this
solution is probably fine.) Per buildfarm results.

Bruce Momjian committed:

- Move USE_WIDE_UPPER_LOWER define to c.h, and remove TS_USE_WIDE and

- In pgsql/src/backend/utils/mb/README, add URL for introduction to
multibyte programming in C.

- Move wchar2char() and char2wchar() from tsearch into /mb to be
easier to use for other modules; also move pnstrdup(). Clean up
code slightly.

- Add URL for TODO: "Allow pg_hba.conf to specify host names along
with IP addresses."

Neil Conway committed:

- In pgsql/doc/src/sgml/monitoring.sgml, fix a few typos in the DTrace
docs. Patch from Euler Taveira de Oliveira, along with an
additional typo I noticed along the way.

Alvaro Herrera committed:

- Improve our #include situation by moving pointer types away from the
corresponding struct definitions. This allows other headers to
avoid including certain highly-loaded headers such as rel.h and
relscan.h, instead using just relcache.h, heapam.h or genam.h, which
are more lightweight and thus cause less unnecessary dependencies.

== Abgelehnte Patches (bis jetzt) ==

No one was disappointed this week :-)

== Eingesandte Patches ==

Zoltan Boszormenyi sent in another revision of his POSIX fadvise

Simon Riggs sent in a patch to improve performance via hint bits for
write I/O.
  • Twitter
  • Bookmark Wöchentlicher PostgreSQL Newsletter - 22. Juni 2008 at
  • Facebook
  • Google Bookmarks
  • FriendFeed
  • Digg Wöchentlicher PostgreSQL Newsletter - 22. Juni 2008
  • Bloglines Wöchentlicher PostgreSQL Newsletter - 22. Juni 2008
  • Technorati Wöchentlicher PostgreSQL Newsletter - 22. Juni 2008
  • Fark this: Wöchentlicher PostgreSQL Newsletter - 22. Juni 2008
  • Bookmark Wöchentlicher PostgreSQL Newsletter - 22. Juni 2008 at YahooMyWeb
  • Bookmark Wöchentlicher PostgreSQL Newsletter - 22. Juni 2008 at
  • Bookmark Wöchentlicher PostgreSQL Newsletter - 22. Juni 2008 at
  • Bookmark Wöchentlicher PostgreSQL Newsletter - 22. Juni 2008 at
  • Bookmark Wöchentlicher PostgreSQL Newsletter - 22. Juni 2008 at
  • Bookmark Wöchentlicher PostgreSQL Newsletter - 22. Juni 2008 at
  • Bookmark Wöchentlicher PostgreSQL Newsletter - 22. Juni 2008 at blogmarks
  • Bookmark Wöchentlicher PostgreSQL Newsletter - 22. Juni 2008 with wists
  • wong it!
  • Bookmark using any bookmark manager!
  • Stumble It!


No Trackbacks


Display comments as Linear | Threaded

No comments

Add Comment

Enclosing asterisks marks text as bold (*word*), underscore are made via _word_.
E-Mail addresses will not be displayed and will only be used for E-Mail notifications.
To leave a comment you must approve it via e-mail, which will be sent to your address after submission.
Form options