> 	o Change syntax to WITH DELIMITER, (keep old syntax around?)

> * Add WAL index reliability improvement to non-btree indexes

< * Improve access-permissions check on data directory in CYGWIN (Tom)
---
> * Improve access-permissions check on data directory in Cygwin (Tom)

<
---
> * Improve access-permissions check on data directory in CYGWIN (Tom)

'volatile' pointers to access those structures, so that optimizing
compilers will not decide to move the structure accesses outside of the
spinlock-acquire-to-spinlock-release sequence.  There are no known bugs
in these uses at present, but based on bad experience with lwlock.c,
it seems prudent to ensure that we protect these other uses too.
Per pghackers discussion around 12-Dec.  (Note: it should not be
necessary to worry about structures protected by LWLocks, since the
LWLock acquire and release operations are not inline macros.)

> * Allow binding query args over FE/BE protocol

> 	o Have ALTER TABLE OWNER change all dependant objects like indexes

< 	o Allow SELECT of array of strings into a auto-sized variable
---
> 	o -Allow SELECT of array of strings into a auto-sized variable

> 	o auto allocation for indicator variable arrays (int *ind_p=NULL)
> 	o auto allocation for string arrays (char **foo_pp=NULL)
> 	o ECPGfree_auto_mem fixed
> 	o all function names with external linkage are now prefixed by ECPG

> * Add OpenBSD's getpeereid() call for local socket authentication (Bruce)

> * -Allow secure single-user access without passwords using Unix socket permissions
> * Make single-user local socket access permissions the default (Peter E)

! * Add PGPASSWORDFILE environment variable or ~/.pgpass to store
!   user/host/password combinations

list:

	* Add optional CRC checksum to heap and index pages

description of COMMENT command.

and Vivek Khera.

now generated from DocBook sources.

- Fixed several bugs concerning arrays of structs including a memory
  allocation bug.

machines.  I have just been observing some scenarios where set_ps_display
accounts for more than 10% of the backend CPU, and this loop has to be
the reason.

Thanks to Greg Sabino Mullane <greg@turnstep.com> for finding the problem.