PROCLOCK structs in shared memory now have only a bitmask for held
locks, rather than counts (making them 40 bytes smaller, which is a
good thing).  Multiple locks within a transaction are counted in the
local hash table instead, and we have provision for tracking which
ResourceOwner each count belongs to.  Solves recently reported problem
with memory leakage within long transactions.

< 	This would require some background daemon to maintain clustering
> 	This might require some background daemon to maintain clustering
397,398c397,398
< 	paritally filled for easier reorganization.  It also might require
< 	creating a merged heap/index data file so an index lookup would
> 	paritally filled for easier reorganization.  Another idea would
>         be to create a merged heap/index data file so an index lookup would

< 	This would require some background daemon to restore clustering
> 	This would require some background daemon to maintain clustering
397c397,399
< 	paritally filled for easier reorganization.
> 	paritally filled for easier reorganization.  It also might require
> 	creating a merged heap/index data file so an index lookup would
> 	automatically access the heap data too.

changes.

CIDR column in examples first.

Jun Kuwamura

> * Merge hardwired timezone names with the TZ database; allow either kind
>   everywhere a TZ name is currently taken
> * Allow customization of the known set of TZ names (generalize the
>   present australian_timezones hack)

for every command executed within a transaction.  For long transactions
this was a significant memory leak.  Instead, we can delete a portal's
or subtransaction's ResourceOwner immediately, if we physically transfer
the information about its locks up to the parent owner.  This does not
fully solve the leak problem; we need to do something about counting
multiple acquisitions of the same lock in order to fix it.  But it's a
necessary step along the way.

ColLabel instead of just ColId --- that is, any keyword can appear after
a dot and it will be taken as an identifier.  Fixes problems with names
that are okay as standalone function names but fail when qualified.

< * Implement dirty reads or shared row locks and use them in RI triggers (?)
> * Implement dirty reads or shared row locks and use them in RI triggers
>
>   Adding shared locks requires recording the table/rows numbers in a
>   shared area, and this could potentially be a large amount of data.
>   One idea is to store the table/row numbers in a separate table and set
>   a bit on the row indicating looking in this new table is required to
>   find any shared row locks.
>

SGML markup, add a "deprecated features" section to the 8.0 release
notes, untabify release.sgml and runtime.sgml, and make some other
minor improvements.

updates are no longer WAL-logged nor even fsync'd; we do not need to,
since after a crash no old pg_subtrans data is needed again.  We truncate
pg_subtrans to RecentGlobalXmin at each checkpoint.  slru.c's API is
refactored a little bit to separate out the necessary decisions.

<   partial page writes during recovery.
>   partial page writes during recovery.  These pages can also be
>   eliminated from point-in-time archive files.

RecentXmin (== MyProc->xmin).  This ensures that it will be safe to
truncate pg_subtrans at RecentGlobalXmin, which should largely eliminate
any fear of bloat.  Along the way, eliminate SubTransXidsHaveCommonAncestor,
which isn't really needed and could not give a trustworthy result anyway
under the lookback restriction.
In an unrelated but nearby change, #ifdef out GetUndoRecPtr, which has
been dead code since 2001 and seems unlikely to ever be resurrected.

linked into the docs ...

in contrib/ltree.  Fix.

on non-gcc compilers.

instead of runtime, for better detection of invalid condition names
(and maybe a little more speed, too).

>>'127.0.0.1/32' instead of '127.0.0.1 255.255.255.255'.
>>
>>
>
>Yeah, that's probably the path of least resistance.  Note that the
>comments and possibly the SGML docs need to be adjusted to match,
>however, so it's not quite a one-liner.

Andrew Dunstan

Greg Sabino Mullan

>
> The patch adds missing the "libpgport.a" file to the installation under
> "install-all-headers". It is needed by some contribs. I install the
> library in "pkglibdir", but I was wondering whether it should be "libdir"?
> I was wondering also whether it would make sense to have a "libpgport.so"?
>
> It fixes various macros which are used by contrib makefiles, especially
> libpq_*dir and LDFLAGS when used under PGXS. It seems to me that they are
> needed to
>
> It adds the ability to test and use PGXS with contribs, with "make
> USE_PGXS=1". Without the macro, this is exactly as before, there should be
> no difference, esp. wrt the vpath feature that seemed broken by previous
> submission. So it should not harm anybody, and it is useful at least to me.
>
> It fixes some inconsistencies in various contrib makefiles
> (useless override, ":=" instead of "=").

Fabien COELHO

< 	o Allow databases, schemas, and indexes to be moved to different
< 	  tablespaces
> 	o Allow databases and schemas to be moved to different tablespaces
>
> 	One complexity is whether moving a schema should move all existing
> 	schema objects or just define the location for future object creation.
>
382c385
< 	o Add ALTER INDEX that works just like ALTER TABLE already does
> 	o -Add ALTER INDEX that works just like ALTER TABLE already does
384d386
< 	o Add ALTER INDEX syntax to work like ALTER TABLE indexname

multiline command  or to rerun the command easily later.

Whereas displaying the failed SQL command is a matter of fixing the
error
messages.

The latter is complicated by failed COPY commands which, with
die-on-errors
off, results in the data being processed as a command, so dumping the
command will dump all of the data.

In the case of long commands, should the whole command be dumped? eg.
(eg.
several pages of function definition).

In the case of the COPY command, I'm not sure what to do. Obviously, it
would be best to avoid sending the data, but the data and command are
combined (from memory). Also, the 'data' may be in the form of INSERT
statements.

Attached patch produces the first 125 chars of the command:

pg_restore: [archiver (db)] Error while PROCESSING TOC:
pg_restore: [archiver (db)] Error from TOC Entry 26; 1255 16449270
FUNCTION
plpgsql_call_handler() pjw
pg_restore: [archiver (db)] could not execute query: ERROR:  function
"plpgsql_call_handler" already exists with same argument types
     Command was: CREATE FUNCTION plpgsql_call_handler() RETURNS
language_handler
     AS '/var/lib/pgsql-8.0b1/lib/plpgsql', 'plpgsql_call_han...
pg_restore: [archiver (db)] Error from TOC Entry 27; 1255 16449271
FUNCTION
plpgsql_validator(oid) pjw
pg_restore: [archiver (db)] could not execute query: ERROR:  function
"plpgsql_validator" already exists with same argument types
     Command was: CREATE FUNCTION plpgsql_validator(oid) RETURNS void
     AS '/var/lib/pgsql-8.0b1/lib/plpgsql', 'plpgsql_validator'
     LANGU...

Philip Warner