[COMMITTERS] pgsql: Convert wal_sync_method to guc enum.

2008-05-12 Thread Magnus Hagander
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/u

[COMMITTERS] pgsql: Report which WAL sync method we are trying to change *to* when it

2008-05-12 Thread Magnus Hagander
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://ano

Re: [COMMITTERS] pgsql: Convert wal_sync_method to guc enum.

2008-05-12 Thread Tom Lane
[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.

Re: [COMMITTERS] pgsql: Convert wal_sync_method to guc enum.

2008-05-12 Thread Magnus Hagander
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

[COMMITTERS] pgsql: Put back bufmgr.h in bufpage.h -- it is needed by some macros.

2008-05-12 Thread Alvaro Herrera
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://ano

[COMMITTERS] pgsql: Document that "ROLLBACK TO savepoint" does not un-close cursors.

2008-05-12 Thread Alvaro Herrera
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 v

[COMMITTERS] pgsql: Check for non-existant connection in prepare statement handling.

2008-05-12 Thread Michael Meskes
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/interfac

[COMMITTERS] pgsql: Check for non-existant connection in prepare statement handling.

2008-05-12 Thread Michael Meskes
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.postgres

Re: [COMMITTERS] pgsql: Report which WAL sync method we are trying to change *to* when it

2008-05-12 Thread Simon Riggs
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 abl

Re: [COMMITTERS] pgsql: Report which WAL sync method we are trying to change *to* when it

2008-05-12 Thread Magnus Hagander
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 perspect

Re: [COMMITTERS] pgsql: Report which WAL sync method we are trying to change *to* when it

2008-05-12 Thread Tom Lane
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 a

Re: [COMMITTERS] pgsql: Report which WAL sync method we are trying to change *to* when it

2008-05-12 Thread Simon Riggs
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

[COMMITTERS] pgsql: Fix breakage by the wal_sync_method patch in installations that

2008-05-12 Thread Magnus Hagander
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.postgresq

Re: [COMMITTERS] pgsql: Report which WAL sync method we are trying to change *to* when it

2008-05-12 Thread Magnus Hagander
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 valu

Re: [COMMITTERS] pgsql: Report which WAL sync method we are trying to change *to* when it

2008-05-12 Thread Tom Lane
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 (whi

Re: [COMMITTERS] pgsql: Report which WAL sync method we are trying to change *to* when it

2008-05-12 Thread Simon Riggs
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 t

[COMMITTERS] pgsql: Improve snapshot manager by keeping explicit track of snapshots.

2008-05-12 Thread Alvaro Herrera
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 "acti

[COMMITTERS] pgsql: Todo done: > * -Improve dead row detection during

2008-05-12 Thread Bruce Momjian
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/FA

[COMMITTERS] pgsql: Improve psql's internal print.c code by introducing an actual

2008-05-12 Thread Alvaro Herrera
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 th

[COMMITTERS] pgsql: Fix a bug in the previous patch, which caused the title pointer

2008-05-12 Thread Alvaro Herrera
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/describ

[COMMITTERS] pgsql: Change \du to use the new printTable API, improving the situation

2008-05-12 Thread Alvaro Herrera
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/pgs