RE: [HACKERS] Re: possible row locking bug in 7.0.3 & 7.1

> > I don't think that we dare try to make any basic changes in 
> > MVCC for 7.1 at this late hour, so Forest is going to have
> > to live with that answer for awhile. But I would like to see
> > a cleaner answer in future releases.
> 
> Is it the MVCC's restriction that each query inside a function
> must use the same snapshot ?

No. MVCC restricts what is visible to query itself. Current
function' behaviour is like Oracle' one.
Strictly speaking queries inside function don't use the same
snapshot - they see changes made by other queries of this
function. Should we allow them see changes made by other
transactions? I'm not sure. Maybe by special means like
CREATE SNAPSHOT S;
SELECT FROM foo WITH SNAPSHOT S;
?

For this particular case - concurrent UPDATE then
UPDATE/DELETE + SELECT - there is simple solution: meeting
tuple updated by concurrent *committed* transaction
SELECT (in READ COMMITTED mode) should look in newer tuple
versions. If some of newer tuples is invalidated (updated/deleted)
by *this* transaction and this invalidation is *visible*
to SELECT (older CommandId) then old tuple version must not
be returned (newer tuple version will be returned of course).
Reported problem is caused by bug (only one tuple version must be
returned by SELECT) and this is way to fix it.

But note that for the case of concurrent DELETE then
INSERT + SELECT two tuples will be returned anyway and
I don't think that this is bug.

> > As I've opined before, the whole EvalPlanQual mechanism
> > strikes me as essentially bogus in any case...
> 
> How would you change it ? UPDATE/SELECT FOR UPDATE have to
> SELECT/UPDATE the latest tuples. I don't think of any simple
> way for 'SELECT FOR UPDATE' to have the same visibility as
> simple SELECT.

Yes, I also don't understand what's wrong with EvalPlanQual.

Vadim