> > >> I assume this is not possible in 7.1?
> > >
> > >Just looked in heapam.c - I can fix it in two hours.
> > >The question is - should we do this now?
> > >Comments?
> > 
> > It's a bug; how confident are you of the fix?

95% -:)

> 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:

HeapTupleSatisfies(T) is TRUE:

IF XactIsoLevel is READ_COMMITTED
and snapshot != SnapshotDirty
and !(T->t_data->t_infomask & HEAP_XMAX_INVALID)
and T->t_data->t_infomask & HEAP_XMAX_COMMITTED
and T->t_self != T->t_data->t_ctid
{
  FOR ( ; ; )
  {
    fetch tuple->t_data->t_ctid tuple
    IF t_infomask & (HEAP_XMAX_INVALID | HEAP_MARKED_FOR_UPDATE)
      break; -- and return T
    IF t_infomask & HEAP_XMAX_COMMITTED
    {
      IF t_self != ctid	-- updated
        continue;
      break; -- deleted, return T
    }
    -- uncommitted update/delete
    IF t_xmax != CurrentTransactionID
      break; -- and return T
    -- changed by current TX!
    IF changed *BEFORE* this query began
    {
      -- DELETE + SELECT: nothing to return
      -- UPDATE + SELECT: newer tuple version
      -- will be/was returned by query
      return NULL;
    }
    continue;
  }
}

Vadim

Thu, 29 Mar 2001 21:17:50 -0800
"Mikheev, Vadim" <vmikheev@SECTORBASE.COM>
RE: [HACKERS] Re: possible row locking bug in 7.0.3 & 7.1
"Mikheev, Vadim" wrote:
> 
> > > >> I assume this is not possible in 7.1?
> > > >
> > > >Just looked in heapam.c - I can fix it in two hours.
> > > >The question is - should we do this now?
> > > >Comments?
> > >
> > > It's a bug; how confident are you of the fix?
> 
> 95% -:)
> 
> > 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.
SELECT doesn't seem guilty but the result is far 
from intuitive.
It seems impossoble for all queires inside such
a function to use a common snapshot.

regards,
Hiroshi Inoue

Fri, 30 Mar 2001 19:15:22 +0900
Hiroshi Inoue <Inoue@tpf.co.jp>
Re: [HACKERS] Re: possible row locking bug in 7.0.3 & 7.1