Gavin Sherry

pg_clog, there's no reason to do abort marking of subtransactions in a
nonintuitive order.

TransactionIdDidCommit.

available elsewhere (including a descendant project on gborg).

so that we close and flush the doomed relation's relcache entry before
we start to delete the underlying catalog rows, rather than afterwards.
For awhile yesterday I thought that an unexpected relcache entry rebuild
partway through this sequence might explain the infrequent parallel
regression failures we were chasing.  It doesn't, mainly because there's
no CommandCounterIncrement in the sequence and so the deletions aren't
"really" done yet.  But it sure seems like trouble waiting to happen.

> > "pg_ctl register -w ...." the "-w" parameter was not put in
> the registry "ImagePath"
> > value for the Postgres service. (I added it manually to test.) So I
> > suspect that "pg_ctl register" will need to be enhanced to add the
> > "-w" parameter to the registry settings.

Dave Page

Magnus Hagander

relcache entries.  Also, change TransactionIdIsCurrentTransactionId()
so that if consulted during transaction abort, it will not say that
the aborted xact is still current.  (It would be better to ensure that
it's never called at all during abort, but I'm not sure we can easily
guarantee that.)  In combination, these fix a crash we have seen
occasionally during parallel regression tests of 8.0.

from being accepted after the outer right brace. Per report from
Markus Bertheau.

Also add regression test cases for this change, and for previous
recent array literal parser changes.

module isn't fully initialized yet.

if the target PID is a PG postmaster or backend --- for our purposes that
is actually better than the Unix behavior.  Per Dave Page and Andrew Dunstan.

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.