On Thu, 2009-09-24 at 13:33 +0300, Heikki Linnakangas wrote: > Heikki Linnakangas wrote: > > The problem becomes a lot easier if we accept that it's OK to have a > > lock included in the running-xacts snapshot and also appear in a > > XLOG_RELATION_LOCK record later. The standby should handle that > > gracefully already. If we just remove RecoveryInfoLock, that can happen, > > but it still won't be possible for a lock to be missed out which is what > > we really care about. > > I see the problem with that now. Without the lock, it's possible that > the XLOG_RELATION_LOCK WAL record is written before the > XLOG_RUNNING_XACTS record. If the lock is not included in the snapshot, > we want the lock WAL record to be after the snapshot record. > > So i guess we'll need the RecoveryInfoLock. But we don't need to hold it > across the wait. I think it's enough to acquire it just before writing > the WAL record in LockAcquire. That will ensure that the WAL record > isn't written until the snapshot is completely finished.
I will think some more on that. I remember thinking there was a reason why that wasn't enough, possibly to do with no-wait locks which I remember caused me to change that code. -- Simon Riggs www.2ndQuadrant.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
