[COMMITTERS] pgsql: Convert wal_sync_method to guc enum.
Log Message: --- Convert wal_sync_method to guc enum. Modified Files: -- pgsql/src/backend/access/transam: xlog.c (r1.303 -> r1.304) (http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/backend/access/transam/xlog.c?r1=1.303&r2=1.304) pgsql/src/backend/utils/misc: guc.c (r1.452 -> r1.453) (http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/backend/utils/misc/guc.c?r1=1.452&r2=1.453) pgsql/src/include/access: xlog.h (r1.87 -> r1.88) (http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/include/access/xlog.h?r1=1.87&r2=1.88) xlogdefs.h (r1.19 -> r1.20) (http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/include/access/xlogdefs.h?r1=1.19&r2=1.20) pgsql/src/include/utils: guc.h (r1.94 -> r1.95) (http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/include/utils/guc.h?r1=1.94&r2=1.95) -- Sent via pgsql-committers mailing list ([email protected]) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-committers
[COMMITTERS] pgsql: Report which WAL sync method we are trying to change *to* when it
Log Message: --- Report which WAL sync method we are trying to change *to* when it fails, not which one we had before (that worked, and thus is completley irrelevant) Modified Files: -- pgsql/src/backend/access/transam: xlog.c (r1.304 -> r1.305) (http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/backend/access/transam/xlog.c?r1=1.304&r2=1.305) -- Sent via pgsql-committers mailing list ([email protected]) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-committers
Re: [COMMITTERS] pgsql: Convert wal_sync_method to guc enum.
[EMAIL PROTECTED] (Magnus Hagander) writes: > Convert wal_sync_method to guc enum. Buildfarm says you broke things for Windows. regards, tom lane -- Sent via pgsql-committers mailing list ([email protected]) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-committers
Re: [COMMITTERS] pgsql: Convert wal_sync_method to guc enum.
Tom Lane wrote: > [EMAIL PROTECTED] (Magnus Hagander) writes: > > Convert wal_sync_method to guc enum. > > Buildfarm says you broke things for Windows. Yeah, working on that with Dave. First part was to unbreak the error message so we can actually figure out what's broken :-( //Magnus -- Sent via pgsql-committers mailing list ([email protected]) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-committers
[COMMITTERS] pgsql: Put back bufmgr.h in bufpage.h -- it is needed by some macros.
Log Message: --- Put back bufmgr.h in bufpage.h -- it is needed by some macros. Remove #include bufmgr.h from (most?) source files which already include bufpage.h. Modified Files: -- pgsql/src/backend/access/gin: ginentrypage.c (r1.13 -> r1.14) (http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/backend/access/gin/ginentrypage.c?r1=1.13&r2=1.14) pgsql/src/backend/access/heap: heapam.c (r1.256 -> r1.257) (http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/backend/access/heap/heapam.c?r1=1.256&r2=1.257) hio.c (r1.69 -> r1.70) (http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/backend/access/heap/hio.c?r1=1.69&r2=1.70) pruneheap.c (r1.10 -> r1.11) (http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/backend/access/heap/pruneheap.c?r1=1.10&r2=1.11) rewriteheap.c (r1.11 -> r1.12) (http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/backend/access/heap/rewriteheap.c?r1=1.11&r2=1.12) pgsql/src/backend/access/transam: xlog.c (r1.305 -> r1.306) (http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/backend/access/transam/xlog.c?r1=1.305&r2=1.306) xlogutils.c (r1.52 -> r1.53) (http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/backend/access/transam/xlogutils.c?r1=1.52&r2=1.53) pgsql/src/backend/commands: analyze.c (r1.120 -> r1.121) (http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/backend/commands/analyze.c?r1=1.120&r2=1.121) pgsql/src/backend/storage/buffer: bufmgr.c (r1.229 -> r1.230) (http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/backend/storage/buffer/bufmgr.c?r1=1.229&r2=1.230) pgsql/src/include/storage: bufpage.h (r1.78 -> r1.79) (http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/include/storage/bufpage.h?r1=1.78&r2=1.79) -- Sent via pgsql-committers mailing list ([email protected]) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-committers
[COMMITTERS] pgsql: Document that "ROLLBACK TO savepoint" does not un-close cursors.
Log Message: --- Document that "ROLLBACK TO savepoint" does not un-close cursors. Modified Files: -- pgsql/doc/src/sgml/ref: close.sgml (r1.26 -> r1.27) (http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/doc/src/sgml/ref/close.sgml?r1=1.26&r2=1.27) -- Sent via pgsql-committers mailing list ([email protected]) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-committers
[COMMITTERS] pgsql: Check for non-existant connection in prepare statement handling.
Log Message: --- Check for non-existant connection in prepare statement handling. Do not close files that weren't opened. Modified Files: -- pgsql/src/interfaces/ecpg: ChangeLog (r1.380 -> r1.381) (http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/interfaces/ecpg/ChangeLog?r1=1.380&r2=1.381) pgsql/src/interfaces/ecpg/ecpglib: prepare.c (r1.26 -> r1.27) (http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/interfaces/ecpg/ecpglib/prepare.c?r1=1.26&r2=1.27) pgsql/src/interfaces/ecpg/preproc: preproc.y (r1.363 -> r1.364) (http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/interfaces/ecpg/preproc/preproc.y?r1=1.363&r2=1.364) -- Sent via pgsql-committers mailing list ([email protected]) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-committers
[COMMITTERS] pgsql: Check for non-existant connection in prepare statement handling.
Log Message: --- Check for non-existant connection in prepare statement handling. Do not close files that weren't opened. Tags: REL8_3_STABLE Modified Files: -- pgsql/src/interfaces/ecpg/ecpglib: prepare.c (r1.26 -> r1.26.2.1) (http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/interfaces/ecpg/ecpglib/prepare.c?r1=1.26&r2=1.26.2.1) pgsql/src/interfaces/ecpg/preproc: preproc.y (r1.359.2.2 -> r1.359.2.3) (http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/interfaces/ecpg/preproc/preproc.y?r1=1.359.2.2&r2=1.359.2.3) -- Sent via pgsql-committers mailing list ([email protected]) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-committers
Re: [COMMITTERS] pgsql: Report which WAL sync method we are trying to change *to* when it
On Mon, 2008-05-12 at 14:27 +, Magnus Hagander wrote: > Log Message: > --- > Report which WAL sync method we are trying to change *to* when it fails, > not which one we had before (that worked, and thus is completley irrelevant) Interesting perspective. If it breaks, I'd rather be able to put it back the way it was than regret in technicolour that my new choice was a bad one. ;-) Not everybody keeps a change log. Could we report both? -- Simon Riggs 2ndQuadrant http://www.2ndQuadrant.com -- Sent via pgsql-committers mailing list ([email protected]) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-committers
Re: [COMMITTERS] pgsql: Report which WAL sync method we are trying to change *to* when it
Simon Riggs wrote: > On Mon, 2008-05-12 at 14:27 +, Magnus Hagander wrote: > > Log Message: > > --- > > Report which WAL sync method we are trying to change *to* when it > > fails, not which one we had before (that worked, and thus is > > completley irrelevant) > > Interesting perspective. > > If it breaks, I'd rather be able to put it back the way it was than > regret in technicolour that my new choice was a bad one. ;-) Well, the message itself indicated that it was the new one... > Not everybody keeps a change log. > > Could we report both? Yes, we could easily do that if we want to. But - this is not the error you get when you try to set it. It's the error you get when you try to *use* it. And really, it's a "should never happen" error. (The reason it happens this time is due to another bug). So I don't think doing so would actually help your case - it's already covered elsewhere in the code where we'll rollback the setting when you try to change it instead of PANICing. //Magnus -- Sent via pgsql-committers mailing list ([email protected]) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-committers
Re: [COMMITTERS] pgsql: Report which WAL sync method we are trying to change *to* when it
Magnus Hagander <[EMAIL PROTECTED]> writes: > Simon Riggs wrote: >> Could we report both? > Yes, we could easily do that if we want to. It would be entirely silly to do so, since (a) the old value hasn't been changed if we fail here, and (b) it's irrelevant to the nature of the error. What's also a bit silly is using PANIC for this report --- AFAICS plain old ERROR is sufficient, since if we fail here we have not yet modified any persistent state. Just because it's a "can't happen" condition doesn't justify making it a PANIC. regards, tom lane -- Sent via pgsql-committers mailing list ([email protected]) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-committers
Re: [COMMITTERS] pgsql: Report which WAL sync method we are trying to change *to* when it
On Mon, 2008-05-12 at 15:26 -0400, Tom Lane wrote: > Magnus Hagander <[EMAIL PROTECTED]> writes: > > Simon Riggs wrote: > >> Could we report both? > > > Yes, we could easily do that if we want to. > > It would be entirely silly to do so, since (a) the old value hasn't been > changed if we fail here, and (b) it's irrelevant to the nature of the > error. That's reasonable. If it is impossible to set it to an impossible/failing value then that is even better. Magnus seems to say it is possible to set this and then have it fail later when it is used. Not sure which is correct. -- Simon Riggs 2ndQuadrant http://www.2ndQuadrant.com -- Sent via pgsql-committers mailing list ([email protected]) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-committers
[COMMITTERS] pgsql: Fix breakage by the wal_sync_method patch in installations that
Log Message: --- Fix breakage by the wal_sync_method patch in installations that use O_DSYNC (specifically this broke all the Windows buildfarm members) Modified Files: -- pgsql/src/backend/access/transam: xlog.c (r1.306 -> r1.307) (http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/backend/access/transam/xlog.c?r1=1.306&r2=1.307) -- Sent via pgsql-committers mailing list ([email protected]) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-committers
Re: [COMMITTERS] pgsql: Report which WAL sync method we are trying to change *to* when it
Simon Riggs wrote: > On Mon, 2008-05-12 at 15:26 -0400, Tom Lane wrote: > > Magnus Hagander <[EMAIL PROTECTED]> writes: > > > Simon Riggs wrote: > > >> Could we report both? > > > > > Yes, we could easily do that if we want to. > > > > It would be entirely silly to do so, since (a) the old value hasn't > > been changed if we fail here, and (b) it's irrelevant to the nature > > of the error. > > That's reasonable. If it is impossible to set it to an > impossible/failing value then that is even better. > > Magnus seems to say it is possible to set this and then have it fail > later when it is used. Not sure which is correct. It shouldn't ever happen. It happened here because there was a bug in my original patch, that has now been fixed. So unless there are more bugs in it, it is now back to can't happen. //Magnus -- Sent via pgsql-committers mailing list ([email protected]) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-committers
Re: [COMMITTERS] pgsql: Report which WAL sync method we are trying to change *to* when it
Simon Riggs <[EMAIL PROTECTED]> writes: > Magnus seems to say it is possible to set this and then have it fail > later when it is used. Not sure which is correct. Per his comment just now, I think he'd gotten confused between assign_xlog_sync_method (which sets the value) and issue_xlog_fsync (which uses it). regards, tom lane -- Sent via pgsql-committers mailing list ([email protected]) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-committers
Re: [COMMITTERS] pgsql: Report which WAL sync method we are trying to change *to* when it
On Mon, 2008-05-12 at 21:49 +0200, Magnus Hagander wrote: > Simon Riggs wrote: > > On Mon, 2008-05-12 at 15:26 -0400, Tom Lane wrote: > > > Magnus Hagander <[EMAIL PROTECTED]> writes: > > > > Simon Riggs wrote: > > > >> Could we report both? > > > > > > > Yes, we could easily do that if we want to. > > > > > > It would be entirely silly to do so, since (a) the old value hasn't > > > been changed if we fail here, and (b) it's irrelevant to the nature > > > of the error. > > > > That's reasonable. If it is impossible to set it to an > > impossible/failing value then that is even better. > > > > Magnus seems to say it is possible to set this and then have it fail > > later when it is used. Not sure which is correct. > > It shouldn't ever happen. It happened here because there was a bug in > my original patch, that has now been fixed. So unless there are more > bugs in it, it is now back to can't happen. OK, good. Just checking it won't ever happen to me ;-) (and if it does, I have a backout plan). -- Simon Riggs 2ndQuadrant http://www.2ndQuadrant.com -- Sent via pgsql-committers mailing list ([email protected]) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-committers
[COMMITTERS] pgsql: Improve snapshot manager by keeping explicit track of snapshots.
Log Message: --- Improve snapshot manager by keeping explicit track of snapshots. There are two ways to track a snapshot: there's the "registered" list, which is used for arbitrary long-lived snapshots; and there's the "active stack", which is used for the snapshot that is considered "active" at any time. This also allows users of snapshots to stop worrying about snapshot memory allocation and freeing, and about using PG_TRY blocks around ActiveSnapshot assignment. This is all done automatically now. As a consequence, this allows us to reset MyProc->xmin when there are no more snapshots registered in the current backend, reducing the impact that long-running transactions have on VACUUM. Modified Files: -- pgsql/src/backend/access/transam: xact.c (r1.263 -> r1.264) (http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/backend/access/transam/xact.c?r1=1.263&r2=1.264) pgsql/src/backend/catalog: index.c (r1.298 -> r1.299) (http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/backend/catalog/index.c?r1=1.298&r2=1.299) pgsql/src/backend/commands: cluster.c (r1.175 -> r1.176) (http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/backend/commands/cluster.c?r1=1.175&r2=1.176) copy.c (r1.298 -> r1.299) (http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/backend/commands/copy.c?r1=1.298&r2=1.299) explain.c (r1.173 -> r1.174) (http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/backend/commands/explain.c?r1=1.173&r2=1.174) indexcmds.c (r1.175 -> r1.176) (http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/backend/commands/indexcmds.c?r1=1.175&r2=1.176) portalcmds.c (r1.73 -> r1.74) (http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/backend/commands/portalcmds.c?r1=1.73&r2=1.74) prepare.c (r1.86 -> r1.87) (http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/backend/commands/prepare.c?r1=1.86&r2=1.87) trigger.c (r1.232 -> r1.233) (http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/backend/commands/trigger.c?r1=1.232&r2=1.233) vacuum.c (r1.372 -> r1.373) (http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/backend/commands/vacuum.c?r1=1.372&r2=1.373) variable.c (r1.127 -> r1.128) (http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/backend/commands/variable.c?r1=1.127&r2=1.128) pgsql/src/backend/executor: execMain.c (r1.308 -> r1.309) (http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/backend/executor/execMain.c?r1=1.308&r2=1.309) functions.c (r1.124 -> r1.125) (http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/backend/executor/functions.c?r1=1.124&r2=1.125) spi.c (r1.194 -> r1.195) (http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/backend/executor/spi.c?r1=1.194&r2=1.195) pgsql/src/backend/storage/ipc: procarray.c (r1.43 -> r1.44) (http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/backend/storage/ipc/procarray.c?r1=1.43&r2=1.44) pgsql/src/backend/storage/large_object: inv_api.c (r1.132 -> r1.133) (http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/backend/storage/large_object/inv_api.c?r1=1.132&r2=1.133) pgsql/src/backend/tcop: fastpath.c (r1.99 -> r1.100) (http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/backend/tcop/fastpath.c?r1=1.99&r2=1.100) postgres.c (r1.551 -> r1.552) (http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/backend/tcop/postgres.c?r1=1.551&r2=1.552) pquery.c (r1.122 -> r1.123) (http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/backend/tcop/pquery.c?r1=1.122&r2=1.123) pgsql/src/backend/utils/adt: ri_triggers.c (r1.107 -> r1.108) (http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/backend/utils/adt/ri_triggers.c?r1=1.107&r2=1.108) txid.c (r1.6 -> r1.7) (http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/backend/utils/adt/txid.c?r1=1.6&r2=1.7) pgsql/src/backend/utils/cache: plancache.c (r1.17 -> r1.18) (http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/backend/utils/cache/plancache.c?r1=1.17&r2=1.18) pgsql/src/backend/utils/time: snapmgr.c (r1.1 -> r1.2) (http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/backend/utils/time/snapmgr.c?r1=1.1&r2=1.2) pgsql/src/include/storage: procarray.h (r1.21 -> r1.22) (http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/include/storage/procarray.h?r1=1.21&r2=1.22) pgsql/src/include/utils: snapmgr.h (r1.1 -> r1.2) (http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/include/utils/snapmgr.h?r1=1.1&r2=1.2) snapshot.h (r1.2 -> r1.3) (http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/include/utils/snapshot.h?r1=1.2&r2=1.3) pgsql/src/pl/plpgsql/src: pl_exec.c (r1.212 -> r1.213) (http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/pl/plpgsql/src/pl_exec
[COMMITTERS] pgsql: Todo done: > * -Improve dead row detection during
Log Message: --- Todo done: > * -Improve dead row detection during multi-statement transactions usage Modified Files: -- pgsql/doc: TODO (r1.2456 -> r1.2457) (http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/doc/TODO?r1=1.2456&r2=1.2457) pgsql/doc/src/FAQ: TODO.html (r1.962 -> r1.963) (http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/doc/src/FAQ/TODO.html?r1=1.962&r2=1.963) -- Sent via pgsql-committers mailing list ([email protected]) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-committers
[COMMITTERS] pgsql: Improve psql's internal print.c code by introducing an actual
Log Message: --- Improve psql's internal print.c code by introducing an actual print API. Provides for better code readability, but mainly this is infrastructure changes to allow further changes such as arbitrary footers on printed tables. Also, the translation status of each element in the table is more easily customized. Brendan Jurd, with some editorialization by me. Modified Files: -- pgsql/src/bin/psql: describe.c (r1.170 -> r1.171) (http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/bin/psql/describe.c?r1=1.170&r2=1.171) print.c (r1.99 -> r1.100) (http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/bin/psql/print.c?r1=1.99&r2=1.100) print.h (r1.36 -> r1.37) (http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/bin/psql/print.h?r1=1.36&r2=1.37) pgsql/src/bin/scripts: common.c (r1.31 -> r1.32) (http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/bin/scripts/common.c?r1=1.31&r2=1.32) -- Sent via pgsql-committers mailing list ([email protected]) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-committers
[COMMITTERS] pgsql: Fix a bug in the previous patch, which caused the title pointer
Log Message: --- Fix a bug in the previous patch, which caused the title pointer to be used before it was actually set. Modified Files: -- pgsql/src/bin/psql: describe.c (r1.171 -> r1.172) (http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/bin/psql/describe.c?r1=1.171&r2=1.172) print.c (r1.100 -> r1.101) (http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/bin/psql/print.c?r1=1.100&r2=1.101) -- Sent via pgsql-committers mailing list ([email protected]) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-committers
[COMMITTERS] pgsql: Change \du to use the new printTable API, improving the situation
Log Message: --- Change \du to use the new printTable API, improving the situation of very wide tables. Brendan Jurd, with some help from me. Modified Files: -- pgsql/src/bin/psql: describe.c (r1.172 -> r1.173) (http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/bin/psql/describe.c?r1=1.172&r2=1.173) -- Sent via pgsql-committers mailing list ([email protected]) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-committers
