[COMMITTERS] mysql2pgsql - mysql2pgsql: Float types conversion was still not
Log Message: --- Float types conversion was still not converting properly double(1,2) -> double precision Modified Files: -- mysql2pgsql: mysql2pgsql.perl (r1.2 -> r1.3) (http://cvs.pgfoundry.org/cgi-bin/cvsweb.cgi/mysql2pgsql/mysql2pgsql/mysql2pgsql.perl.diff?r1=1.2&r2=1.3) ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
[COMMITTERS] pgbouncer - pgbouncer: tabify functions, remove unnecessary and buggy
Log Message: --- tabify functions, remove unnecessary and buggy memset Modified Files: -- pgbouncer/src: util.c (r1.10 -> r1.11) (http://cvs.pgfoundry.org/cgi-bin/cvsweb.cgi/pgbouncer/pgbouncer/src/util.c.diff?r1=1.10&r2=1.11) ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
[COMMITTERS] pgsql: Fix two bugs induced in VACUUM FULL by async-commit patch.
Log Message: --- Fix two bugs induced in VACUUM FULL by async-commit patch. First, we cannot assume that XLogAsyncCommitFlush guarantees hint bits will be settable, because clog.c's inexact LSN bookkeeping results in windows where a previously flushed transaction is considered unhintable because it shares an LSN slot with a later unflushed transaction. But repair_frag requires XMIN_COMMITTED to be correct so that it can distinguish tuples moved by the current vacuum. Since not being able to set the bit is an uncommon corner case, the most practical way of dealing with it seems to be to abandon shrinking (ie, don't invoke repair_frag) when we find a non-dead tuple whose XMIN_COMMITTED bit couldn't be set. Second, it is possible for the same reason that a RECENTLY_DEAD tuple does not get its XMAX_COMMITTED bit set during scan_heap. But by the time repair_frag examines the tuple it might be possible to set the bit. We therefore must take buffer content lock when calling HeapTupleSatisfiesVacuum a second time, else we can get an Assert failure in SetBufferCommitInfoNeedsSave. This latter bug is latent in existing releases, but I think it cannot actually occur without async commit, since the first HeapTupleSatisfiesVacuum call should always have set the bit. So I'm not going to back-patch it. In passing, reduce the existing "cannot shrink relation" messages from NOTICE to LOG level. The new message must be no higher than LOG if we don't want unpredictable regression test failures, and consistency seems like a good idea. Also arrange that only one such message is reported per VACUUM FULL; in typical scenarios you could get spammed with many such messages, which seems a bit useless. Modified Files: -- pgsql/src/backend/access/transam: xlog.c (r1.277 -> r1.278) (http://developer.postgresql.org/cvsweb.cgi/pgsql/src/backend/access/transam/xlog.c?r1=1.277&r2=1.278) pgsql/src/backend/commands: vacuum.c (r1.354 -> r1.355) (http://developer.postgresql.org/cvsweb.cgi/pgsql/src/backend/commands/vacuum.c?r1=1.354&r2=1.355) ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
[COMMITTERS] pgbouncer - pgbouncer: Magic number and error message cleanup.
Log Message: --- Magic number and error message cleanup. Thanks to David Fetter Modified Files: -- pgbouncer/src: admin.c (r1.14 -> r1.15) (http://cvs.pgfoundry.org/cgi-bin/cvsweb.cgi/pgbouncer/pgbouncer/src/admin.c.diff?r1=1.14&r2=1.15) bouncer.h (r1.10 -> r1.11) (http://cvs.pgfoundry.org/cgi-bin/cvsweb.cgi/pgbouncer/pgbouncer/src/bouncer.h.diff?r1=1.10&r2=1.11) client.c (r1.12 -> r1.13) (http://cvs.pgfoundry.org/cgi-bin/cvsweb.cgi/pgbouncer/pgbouncer/src/client.c.diff?r1=1.12&r2=1.13) janitor.c (r1.14 -> r1.15) (http://cvs.pgfoundry.org/cgi-bin/cvsweb.cgi/pgbouncer/pgbouncer/src/janitor.c.diff?r1=1.14&r2=1.15) loader.c (r1.4 -> r1.5) (http://cvs.pgfoundry.org/cgi-bin/cvsweb.cgi/pgbouncer/pgbouncer/src/loader.c.diff?r1=1.4&r2=1.5) objects.c (r1.19 -> r1.20) (http://cvs.pgfoundry.org/cgi-bin/cvsweb.cgi/pgbouncer/pgbouncer/src/objects.c.diff?r1=1.19&r2=1.20) pooler.c (r1.4 -> r1.5) (http://cvs.pgfoundry.org/cgi-bin/cvsweb.cgi/pgbouncer/pgbouncer/src/pooler.c.diff?r1=1.4&r2=1.5) util.c (r1.11 -> r1.12) (http://cvs.pgfoundry.org/cgi-bin/cvsweb.cgi/pgbouncer/pgbouncer/src/util.c.diff?r1=1.11&r2=1.12) ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
[COMMITTERS] pgsql: TEMPORARILY make synchronous_commit default to OFF, so that we
Log Message: --- TEMPORARILY make synchronous_commit default to OFF, so that we can get more thorough testing of async-commit mode from the buildfarm. This patch MUST get reverted before 8.3 release! Modified Files: -- pgsql/doc/src/sgml: config.sgml (r1.136 -> r1.137) (http://developer.postgresql.org/cvsweb.cgi/pgsql/doc/src/sgml/config.sgml?r1=1.136&r2=1.137) pgsql/src/backend/utils/misc: guc.c (r1.411 -> r1.412) (http://developer.postgresql.org/cvsweb.cgi/pgsql/src/backend/utils/misc/guc.c?r1=1.411&r2=1.412) pgsql/src/tools: RELEASE_CHANGES (r1.73 -> r1.74) (http://developer.postgresql.org/cvsweb.cgi/pgsql/src/tools/RELEASE_CHANGES?r1=1.73&r2=1.74) ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
[COMMITTERS] pgbouncer - pgbouncer: More magic cleanup, found even couple potential
Log Message: --- More magic cleanup, found even couple potential bugs. - get_header() allowed < 5 length, which could trigger unsigned overflow. - error from server when setting parameters did not do "return false" - broken ParameterStatus should close connection. Again, thanks to David Fetter who pushed for cleaner code. Modified Files: -- pgbouncer/src: admin.c (r1.15 -> r1.16) (http://cvs.pgfoundry.org/cgi-bin/cvsweb.cgi/pgbouncer/pgbouncer/src/admin.c.diff?r1=1.15&r2=1.16) bouncer.h (r1.11 -> r1.12) (http://cvs.pgfoundry.org/cgi-bin/cvsweb.cgi/pgbouncer/pgbouncer/src/bouncer.h.diff?r1=1.11&r2=1.12) client.c (r1.13 -> r1.14) (http://cvs.pgfoundry.org/cgi-bin/cvsweb.cgi/pgbouncer/pgbouncer/src/client.c.diff?r1=1.13&r2=1.14) proto.c (r1.7 -> r1.8) (http://cvs.pgfoundry.org/cgi-bin/cvsweb.cgi/pgbouncer/pgbouncer/src/proto.c.diff?r1=1.7&r2=1.8) server.c (r1.11 -> r1.12) (http://cvs.pgfoundry.org/cgi-bin/cvsweb.cgi/pgbouncer/pgbouncer/src/server.c.diff?r1=1.11&r2=1.12) takeover.c (r1.4 -> r1.5) (http://cvs.pgfoundry.org/cgi-bin/cvsweb.cgi/pgbouncer/pgbouncer/src/takeover.c.diff?r1=1.4&r2=1.5) ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [COMMITTERS] pgsql: Fix two bugs induced in VACUUM FULL byasync-commit patch.
On Mon, 2007-08-13 at 19:08 +, Tom Lane wrote: > Log Message: > --- > Fix two bugs induced in VACUUM FULL by async-commit patch. > > First, we cannot assume that XLogAsyncCommitFlush guarantees hint bits will be > settable, because clog.c's inexact LSN bookkeeping results in windows where a > previously flushed transaction is considered unhintable because it shares an > LSN slot with a later unflushed transaction. But repair_frag requires > XMIN_COMMITTED to be correct so that it can distinguish tuples moved by the > current vacuum. Since not being able to set the bit is an uncommon corner > case, the most practical way of dealing with it seems to be to abandon > shrinking (ie, don't invoke repair_frag) when we find a non-dead tuple whose > XMIN_COMMITTED bit couldn't be set. > > Second, it is possible for the same reason that a RECENTLY_DEAD tuple does not > get its XMAX_COMMITTED bit set during scan_heap. But by the time repair_frag > examines the tuple it might be possible to set the bit. We therefore must > take buffer content lock when calling HeapTupleSatisfiesVacuum a second time, > else we can get an Assert failure in SetBufferCommitInfoNeedsSave. This > latter bug is latent in existing releases, but I think it cannot actually > occur without async commit, since the first HeapTupleSatisfiesVacuum call > should always have set the bit. So I'm not going to back-patch it. > > In passing, reduce the existing "cannot shrink relation" messages from NOTICE > to LOG level. The new message must be no higher than LOG if we don't want > unpredictable regression test failures, and consistency seems like a good > idea. Also arrange that only one such message is reported per VACUUM FULL; > in typical scenarios you could get spammed with many such messages, which > seems a bit useless. This is good; I see what you meant now. Thanks. -- Simon Riggs EnterpriseDB http://www.enterprisedb.com ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
