"Kevin Grittner" <Kevin.Grittner@wicourts.gov> writes:
> Hopefully this won't digress into a top-to-bottom discussion of all
> aspects of implementing serializable transactions again, but I have
> what I hope is a quick question.
> The "easy" part of implementing SIREAD level predicate locking
> should be to get a lock on each visible tuple which is read in the
> execution of the plan. Is it safe to assume that ExecStoreTuple is
> used for any such access? It's obviously too low level to be the
> right place to check whether we're in serializable mode and take out
> locks, but if I look at the callers (like IndexNext or TidNext)
> which use a valid buffer in a call to ExecStoreTuple, should I be
> catching all the tuples read from the heap?
It doesn't really matter, because any patch putting such functionality
into ExecStoreTuple would be rejected. It's an utterly inappropriate
place.
If there's any single place where it would be sane to do that, it'd be
ExecScan(). However, that's used for both scans of physical relations
and things like VALUES and function RTEs, so I'm not sure that's a very
good choice either --- having it know where to find the relation being
scanned is really a violation of modularity. I think you'd probably be
best off to put the hook in SeqNext, IndexNext, etc. Sometimes multiple
call sites are the cleanest solution.
Another reason to do that is that you'll need to migrate the
functionality down towards indexes later, so trying to have
one-size-fits-all code that's ignorant of the type of scan being
done seems like a dead end anyway.
regards, tom lane