Re: MVCC catalog access

On 2013-06-05 11:35:58 -0400, Tom Lane wrote:
> Andres Freund <andres(at)2ndquadrant(dot)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