Nuovo Sondaggio: Quale TODO vi piace di più?
== Offerte di lavoro legate a PostgreSQL per il mese di Giugno ==
== PostgreSQL news locali ==
Il primo meeting del TorontoPUG ci sarà il 23 giugno al Rhino.
L'Oklahoma PUG terrà il suo primo meeting il 23 giugno dalle 19:00
alle 21:00 presso Coach's, Norman, OK.
Il meeting di preparazione al PgDay italiano ci sarà mercoledi 25
giugno alle ore 2130 CET via IRC.
Il pgDay di Portland ci sarà il 20 luglio. Poco prima di OSCON.
Il PGCon Brasile 2008 ci sara' il 26 e 27 settembre 2008 a Unicamp, Campinas.
Il PGDay.IT 2008 ci sarà il 17 e 18 ottobre a Prato.
== News su PostgreSQL ==
Planet PostgreSQL: http://www.planetpostgresql.org/
General Bits, archivi e nuovi articoli occasionali:
PostgreSQL Weekly News è stato spedito questa settimana grazie a David
Fetter e Josh Berkus.
Per segnalare news e annunci invia un email in inglese entro le ore 15,
fuso orario della costa orientale degli U.S.A, di domenica.
Per segnalazioni in inglese david(at)fetter(dot)org, per segnalazioni in
Tedesco pwn(at)pgug(dot)de, per segnalazioni in italiano pwn(at)itpug(dot)org
== Patch applicate ==
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
use USE_WIDE_UPPER_LOWER instead.
- 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
- 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.
== Patch rigettate (per ora) ==
Nessuno è stato scontentato questa settimana ;)
== Patch in attesa ==
Zoltan Boszormenyi sent in another revision of his POSIX fadvise
Simon Riggs sent in a patch to improve performance via hint bits for
(all opinions expressed are my own)
PostgreSQL Consulting -> PGHost http://www.pghost.eu
pgsql-it-generale by date
|Next:||From: Giorgio Valoti||Date: 2008-06-29 09:33:07|
|Subject: Re: Float in java, come in Postgres?|
|Previous:||From: Stefano Tranquillini||Date: 2008-06-23 15:48:17|
|Subject: Float in java, come in Postgres?|