On 11 October 2012 19:36, Robert Haas <robertmh...@gmail.com> wrote: > On Thu, Oct 11, 2012 at 2:23 PM, Simon Riggs <si...@2ndquadrant.com> wrote: >> So where's the race? >> >> AFAICS it either waits or it doesn't - the code isn't vague on that >> point. If we wait we set the flag. >> >> The point is that lock waits are pretty rare since most locks are >> compatible, so triggering a second snap if we waited is not any kind >> of problem, even if we waited for a very short time. > > That actually wouldn't fix the problem, because we might have this scenario: > > 1. We take a snapshot. > 2. Some other process commits, clearing its XID from its PGPROC and > releasing locks. > 3. We take a lock.
Hmm, so now the patch author thinks his patch is not just broken with respect to lock waits, but in all cases? Surely the above race condition is obvious, now and before. Why is it suddenly unacceptable? (If you believe that, why on earth did you commit?) Whenever you take a snapshot things can change before you start using it. And as a result all previous releases of Postgres suffer this problem. Ergo, we should defer taking the snapshot until the very last point when we need to use it. Why is that *not* being suggested here? -- Simon Riggs http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
