On 2013-06-05 11:35:58 -0400, Tom Lane wrote: > Andres Freund <and...@2ndquadrant.com> writes: > > On 2013-06-05 15:28:09 +0100, Greg Stark wrote: > >> I thought there were many call sites that were specifically depending > >> on seeing dirty reads to avoid race conditions with other backends -- > >> which probably just narrowed the race condition or created different > >> ones. > > > But SnapshotNow doesn't allow you to do actual dirty reads? > > Yeah. I believe the issue is that we can't simply do MVCC catalog reads > with a snapshot taken at transaction start time or statement start time, > as we would do if executing an MVCC scan for a user query. Rather, the > snapshot has to be recent enough to ensure we see the current definition > of any table we've just acquired lock on, *even if that's newer than the > snapshot prevailing for the user's purposes*. Otherwise we might be > using the wrong rowtype definition or failing to enforce a just-added > constraint.
Oh, definitely. At least Robert's previous prototype tried to do that (although I am not sure if it went far enough). And I'd be surprised the current one wouldn't do so. > The last time we talked about this, we were batting around ideas of > keeping a "current snapshot for catalog purposes", which we'd update > or at least invalidate anytime we acquired a new lock. (In principle, > if that isn't new enough, we have a race condition that we'd better fix > by adding some more locking.) Robert's results seem to say that that > might be unnecessary optimization, and that it'd be sufficient to just > take a new snap each time we need to do a catalog scan. TBH I'm not > sure I believe that; it seems to me that this approach is surely going > to create a great deal more contention from concurrent GetSnapshotData > calls. I still have a hard time believing those results as well, but I think we might have underestimated the effectiveness of the syscache during workloads which are sufficiently concurrent to make locking in GetSnapshotData() a problem. Greetings, Andres Freund -- Andres Freund 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