[COMMITTERS] npgsql - Npgsql: 2006-05-04 Francisco Figueiredo Jr.
Log Message: --- 2006-05-04 Francisco Figueiredo Jr. <[EMAIL PROTECTED]> * NpgsqlCommand.cs: return count for fetch and move, too, patch from Federico Di Gregorio (fog at initd dot org). Changed UpdateOutputParameters to use FieldIndex which now doesn't throw exceptions when not finding fieldName. [gborg 1185] Thanks (regmaster at gmx.li) for heads up patch and Michael Farr (mfarr at paradise dot net dot nz) for heads up and patch. * NpgsqlDataReader.cs: Changed to use FieldIndex which doesn't throw exception anymore. * NpgsqlRowDescription.cs: Changed FieldIndex method to not throw exception anymore. Modified Files: -- Npgsql/src/Npgsql: NpgsqlCommand.cs (r1.95 -> r1.96) (http://cvs.pgfoundry.org/cgi-bin/cvsweb.cgi/npgsql/Npgsql/src/Npgsql/NpgsqlCommand.cs.diff?r1=1.95&r2=1.96) NpgsqlDataReader.cs (r1.48 -> r1.49) (http://cvs.pgfoundry.org/cgi-bin/cvsweb.cgi/npgsql/Npgsql/src/Npgsql/NpgsqlDataReader.cs.diff?r1=1.48&r2=1.49) NpgsqlRowDescription.cs (r1.15 -> r1.16) (http://cvs.pgfoundry.org/cgi-bin/cvsweb.cgi/npgsql/Npgsql/src/Npgsql/NpgsqlRowDescription.cs.diff?r1=1.15&r2=1.16) ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
[COMMITTERS] pgsql: Rethink the locking mechanisms used for CREATE/DROP/RENAME
Log Message: --- Rethink the locking mechanisms used for CREATE/DROP/RENAME DATABASE. The former approach used ExclusiveLock on pg_database, which being a cluster-wide lock meant only one of these operations could proceed at a time; worse, it also blocked all incoming connections in ReverifyMyDatabase. Now that we have LockSharedObject(), we can use locks of different types applied to databases considered as objects. This allows much more flexible management of the interlocking: two CREATE DATABASEs need not block each other, and need not block connections except to the template database being used. Similarly DROP DATABASE doesn't block unrelated operations. The locking used in flatfiles.c is also much narrower in scope than before. Per recent proposal. Modified Files: -- pgsql/doc/src/sgml: manage-ag.sgml (r2.45 -> r2.46) (http://developer.postgresql.org/cvsweb.cgi/pgsql/doc/src/sgml/manage-ag.sgml.diff?r1=2.45&r2=2.46) pgsql/doc/src/sgml/ref: create_database.sgml (r1.44 -> r1.45) (http://developer.postgresql.org/cvsweb.cgi/pgsql/doc/src/sgml/ref/create_database.sgml.diff?r1=1.44&r2=1.45) drop_database.sgml (r1.21 -> r1.22) (http://developer.postgresql.org/cvsweb.cgi/pgsql/doc/src/sgml/ref/drop_database.sgml.diff?r1=1.21&r2=1.22) pgsql/src/backend/catalog: pg_shdepend.c (r1.8 -> r1.9) (http://developer.postgresql.org/cvsweb.cgi/pgsql/src/backend/catalog/pg_shdepend.c.diff?r1=1.8&r2=1.9) pgsql/src/backend/commands: dbcommands.c (r1.180 -> r1.181) (http://developer.postgresql.org/cvsweb.cgi/pgsql/src/backend/commands/dbcommands.c.diff?r1=1.180&r2=1.181) user.c (r1.170 -> r1.171) (http://developer.postgresql.org/cvsweb.cgi/pgsql/src/backend/commands/user.c.diff?r1=1.170&r2=1.171) pgsql/src/backend/storage/lmgr: lmgr.c (r1.82 -> r1.83) (http://developer.postgresql.org/cvsweb.cgi/pgsql/src/backend/storage/lmgr/lmgr.c.diff?r1=1.82&r2=1.83) pgsql/src/backend/utils/init: flatfiles.c (r1.17 -> r1.18) (http://developer.postgresql.org/cvsweb.cgi/pgsql/src/backend/utils/init/flatfiles.c.diff?r1=1.17&r2=1.18) postinit.c (r1.165 -> r1.166) (http://developer.postgresql.org/cvsweb.cgi/pgsql/src/backend/utils/init/postinit.c.diff?r1=1.165&r2=1.166) ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
[COMMITTERS] pgsql: Simplify relcache startup sequence.
Log Message: --- Simplify relcache startup sequence. With the new design of InitPostgres it's not necessary to have three separate calls anymore. This patch also fixes things so we don't try to read pg_internal.init until after we've obtained lock on the target database; which was fairly harmless, but it's certainly cleaner this way. Modified Files: -- pgsql/src/backend/utils/cache: relcache.c (r1.239 -> r1.240) (http://developer.postgresql.org/cvsweb.cgi/pgsql/src/backend/utils/cache/relcache.c.diff?r1=1.239&r2=1.240) pgsql/src/backend/utils/init: postinit.c (r1.166 -> r1.167) (http://developer.postgresql.org/cvsweb.cgi/pgsql/src/backend/utils/init/postinit.c.diff?r1=1.166&r2=1.167) pgsql/src/include/utils: relcache.h (r1.53 -> r1.54) (http://developer.postgresql.org/cvsweb.cgi/pgsql/src/include/utils/relcache.h.diff?r1=1.53&r2=1.54) ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
[COMMITTERS] pgsql: Code review for contrib/pg_freespacemap.
Log Message: --- Code review for contrib/pg_freespacemap. Add a storedpages column to pg_freespacemap_relations --- while one could theoretically get that number by counting rows in pg_freespacemap_pages, it's surely the hard way to do it. Avoid expensive and inconvenient conversion to and from text format. Minor code and docs cleanup. Modified Files: -- pgsql/contrib/pg_freespacemap: README.pg_freespacemap (r1.3 -> r1.4) (http://developer.postgresql.org/cvsweb.cgi/pgsql/contrib/pg_freespacemap/README.pg_freespacemap.diff?r1=1.3&r2=1.4) pg_freespacemap.c (r1.4 -> r1.5) (http://developer.postgresql.org/cvsweb.cgi/pgsql/contrib/pg_freespacemap/pg_freespacemap.c.diff?r1=1.4&r2=1.5) pg_freespacemap.sql.in (r1.4 -> r1.5) (http://developer.postgresql.org/cvsweb.cgi/pgsql/contrib/pg_freespacemap/pg_freespacemap.sql.in.diff?r1=1.4&r2=1.5) ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
[COMMITTERS] pgsql: Don't try to compile SSL CRL support if local SSL installation
Log Message: --- Don't try to compile SSL CRL support if local SSL installation hasn't got it. Per buildfarm failure on 'canary'. Modified Files: -- pgsql/src/backend/libpq: be-secure.c (r1.66 -> r1.67) (http://developer.postgresql.org/cvsweb.cgi/pgsql/src/backend/libpq/be-secure.c.diff?r1=1.66&r2=1.67) ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [COMMITTERS] pgsql: Don't try to compile SSL CRL support if
On Thu, 4 May 2006, Tom Lane wrote: Log Message: --- Don't try to compile SSL CRL support if local SSL installation hasn't got it. Per buildfarm failure on 'canary'. It seems a little bit dangerous to just not check the CRL without so much as a warning message. CRL support came around in openssl 0.9.7 which was quite some time ago. Last time we discussed[1] this it looked like the 0.9.6 branch was still being maintained, but it's been over two years since the last 0.9.6 release[2]. I'd suggest de-supporting 0.9.6 or some sort of log message if there is a CRL file that we're not going to check. Kris Jurka [1] http://archives.postgresql.org/pgsql-committers/2005-07/msg00194.php [2] http://www.openssl.org/news/ ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [COMMITTERS] pgsql: Don't try to compile SSL CRL support if local SSL installation
Kris Jurka <[EMAIL PROTECTED]> writes: > On Thu, 4 May 2006, Tom Lane wrote: >> Don't try to compile SSL CRL support if local SSL installation hasn't >> got it. Per buildfarm failure on 'canary'. > It seems a little bit dangerous to just not check the CRL without so much > as a warning message. [ shrug... ] Anyone who's running openssl 0.9.6, or whatever that is on canary, isn't expecting CRL support anyway. And all I did is restore the behavior we've had for lo these past many years. regards, tom lane ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
