Re: updateable cursors & visibility - Mailing list pgsql-hackers

From Tom Lane
Subject Re: updateable cursors & visibility
Date
Msg-id 20950.1049295531@sss.pgh.pa.us
Whole thread Raw
In response to Re: updateable cursors & visibility  (Gavin Sherry <swm@linuxworld.com.au>)
List pgsql-hackers
Gavin Sherry <swm@linuxworld.com.au> writes:
> Regardless of which, we could insert a special case in ExecutePlan() (or
> somewhere more appropriate?) to test that the tuple returned from the
> lower level ExecTidScan() still satisifies the cursor query. It should be
> sufficient to use HeapTupleSatisfies() or some of the logic there in to do
> this.

I don't think so; you'll need to use EvalPlanQual.  This is not
different from the situation where a regular UPDATE finds a tuple that is
not the latest version of its row.

Should I point out that we already have semantics for that behavior, and
they depend on the serialization mode?  Most of this discussion seems to
completely ignore the MVCC semantics we already have for updates/deletes
applied to rows that aren't current anymore.  ISTM we should stick to
that behavior ...
        regards, tom lane



pgsql-hackers by date:

Previous
From: Gavin Sherry
Date:
Subject: Re: updateable cursors & visibility
Next
From: "John Liu"
Date:
Subject: Re: 7.3.2 make failed on AIX4.3 using native c compiler