2010/6/30 Tom Lane <tgl@sss.pgh.pa.us>:
> Robert Haas <robertmhaas@gmail.com> writes:
>> I think one per database and one extra one for the shared catalogs
>> would be enough. Most transactions would either touch either just the
>> database, or just the shared catalogs, so you'd write the commit
>> record in whichever stream was appropriate. If you had a transaction
>> that touched both, you'd write the commit record in both places, and
>> include in each stream a reference to the other stream. On replay,
>> when you reach a commit record that references the another stream, you
>> pause until the reference stream also reaches the matching commit
>> record. If you reach the end of that WAL stream without finding the
>> commit record, then, in archive recovery, you just keep waiting for
>> more of the stream to arrive; and, in crash recovery, you write a
>> matching commit record at the end of WAL.
>
> Surely you'd have to roll back, not commit, in that situation. You have
> no excuse for assuming that you've replayed all effects of the
> transaction.
Hmm, good point. But you could make it work either way, I think. If
you flush WAL stream A, write commit record to WAL stream B, flush WAL
stream B, write commit record to WAL stream A, then commit is correct.If you write commit record to A, flush A, write
commitrecord to B,
flush B, then abort is correct.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise Postgres Company
