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

> > > I doubt if it's a bug of SELECT. Well what
> > > 'concurrent UPDATE then SELECT FOR UPDATE +
> > > SELECT' return ?
> >
> > I'm going to add additional check to heapgettup and
> > heap_fetch:
>
> SELECT seems to be able to return a different result
> from that of preceding SELECT FOR UPDATE even after
> applying your change.

Oh, you're right. Well, if we really want that SELECT
returns the same result as SELECT FOR UPDATE *in functions*
(out of functions results are already same) then we have to
add some modifications to fix proposed:

1. If newer version of visible tuple T is marked for update by
us *before* query began then do not return T.

2. If tuple T1 is *not visible* because of it was inserted by
concurrent committed TX then check if it's marked for update
by current TX *before* query began and return *this* tuple
version if yes.

This will be in accordance with standard which requires
us return committed (whenever) rows in READ COMMITTED mode.
In fact, in this mode our SELECTs provide higher isolation
than required by standard returning rows committed *before*
query began. Why? Because of SELECT doesn't lock rows and
the same row may be visited by SELECT in join queries
many times - so we have to be protected against concurrent
updates. SELECT FOR UPDATE protects us BUT if query itself
calls some functions which updates queried table then currently
we may lose information that tuple was marked for update before
query began - so updating tuple inserted by concurrent committed
TX and marked for update by us we would have to save its t_cmax
in t_cmin (and either add new flag to t_infomask or don't turn
OFF HEAP_MARKED_FOR_UPDATE in this case).

This is not what I would like to do in 7.1

> SELECT doesn't seem guilty but the result is far
> from intuitive.

I think that SELECT is guilty. At least returning two versions
of the same row! (One that could be fixed easy).

Vadim