< * -Allow savepoints / nested transactions [transactions] (Alvaro)
> * -Allow savepoints / nested transactions (Alvaro)
348a349,353
> * Add an option to automatically use savepoints for each statement in a
>   multi-statement transaction.
>
>   When enabled, this would allow errors in multi-statement transactions
>   to be automatically ignored.

Always create thread-specific variable.

global variables are problematic on this platform.  Simplest solution
seems to be to initialize pthread key variable to 0.  Also, rename this
variable and check_sigpipe_handler to something involving "pq" to
avoid gratuitous pollution of application namespace.

rename/unlink defined later.  Problem exists on MS VC.

Andrew Francis

> 	o Add ALTER INDEX syntax to work like ALTER TABLE indexname

> * Set proper permissions on non-system schemas during db creation
>
>   Currently all schemas are owned by the super-user because they are
>   copied from the template1 database.
>

proposals by Oliver Jowett.  Update documentation.

of XLogInsert had the same sort of checkpoint interlock problem as
RecordTransactionCommit, and indeed I found some.  Btree index build
and ALTER TABLE SET TABLESPACE write data outside the friendly confines
of the buffer manager, and therefore they have to take their own
responsibility for checkpoint interlock.  The easiest solution seems to
be to force smgrimmedsync at the end of the index build or table copy,
even when the operation is being WAL-logged.  This is sufficient since
the new index or table will be of interest to no one if we don't get
as far as committing the current transaction.

therefore starting with GetCurrentTransactionId is wrong.  Fixes
miscomputation of RecentGlobalXmin leading to bizarre behavior
reported by Gavin Sherry.

Oliver Jowett.

mode isn't really serializable.  I had thought this was covered already
in our docs, but I sure can't find it.

>
> * Allow buffered WAL writes and fsync
>
>   Instead of guaranteeing recovery of all committed transactions, this
>   would provide improved performance by delaying WAL writes and fsync
>   so an abrupt operating system restart might lose a few seconds of
>   committed transactions but still be consistent.  We could perhaps
>   remove the 'fsync' parameter (which results in an an inconsistent
>   database) in favor of this capability.

Andrew Dunstan, some further hacking by Tom Lane.

logic a little bit.

in plpgsql, particularly trying to begin/end/rollback a transaction.

back branches later.

patches.

don't hold an open file reference to the original table at the end.
This is a good thing in any case, particularly so on Windows which
cannot drop the table file otherwise.