"Albe Laurenz" <laurenz(dot)albe(at)wien(dot)gv(dot)at> wrote:
> What if there is an index on the "ishighlander" row?
> Then an index scan would find only one candidate to examine,
> and the other rows would not even be touched by the execution plan.
I assume you're talking about this line of your function:
SELECT count(*) INTO n FROM scots WHERE ishighlander;
I'm further assuming that you meant an index on the ishighlander
*column*.
I can think of more than one way to handle that. Off the top of my
head, I think it would work to acquire an update lock on both old and
new index entries for a row when it is updated, and to lock the range
of an index used for a scan with the new SIREAD lock. Or perhaps,
since the row must be visited to test visibility, the update lock
could be on the old and new rows, and the index scan would find the
conflict in that way. Or it could keep track of the various tuples
which represent different mutations of a row, and link back from the
"not visible to me" row which has been updated to true, and find that
it is a mutation of a visible row.
These are important implementation details to be worked out (very
carefully!). I don't claim to have worked through all such details
yet, or even to be familiar enough with the PostgreSQL internals to do
so in a reasonable time. :-(
-Kevin