On Tue, 2009-02-24 at 23:41 +0000, Simon Riggs wrote: > On Tue, 2009-02-24 at 22:29 +0200, Heikki Linnakangas wrote:
> > overwrites subxids array, and will resurrect any already aborted > > subtransaction. > > > > Isn't XLByteLT(proc->lsn, lsn) always true, because 'lsn' is the lsn of > > the WAL record we're redoing, so there can't be any procs with an LSN > > higher than that? > > I'm wondering whether we need those circumstances at all. > > The main role of ProcArrayUpdateRecoveryTransactions() is two-fold > * initialise snapshot when there isn't one > * reduce possibility of FATAL errors that don't write abort records > > Neither of those needs us to update the subxid cache, so we'd be better > off avoiding that altogether in the common case. So we should be able to > ignore the lsn and race conditions altogether. We still have a race condition for the initial snapshot, so your concern still holds. Thanks for highlighting it. I'm in the middle of rewriting ProcArrayUpdateRecoveryTransactions() to avoid errors caused by these race conditions. The LSN flag was an attempt to do that, but was insufficient and has now been removed. I'll discuss it more when I've got it working. Seems like we need working code now rather than lengthy debates. I see a solution and almost have it done. -- Simon Riggs www.2ndQuadrant.com PostgreSQL Training, Services and Support -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
