Re: [HACKERS] Re: possible row locking bug in 7.0.3 & 7.1 - Mailing list pgsql-sql

From Hiroshi Inoue
Subject Re: [HACKERS] Re: possible row locking bug in 7.0.3 & 7.1
Date
Msg-id 3AC45CBA.8CDC3213@tpf.co.jp
Whole thread Raw
List pgsql-sql
"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


pgsql-sql by date:

Previous
From: Philip Warner
Date:
Subject: Re: [HACKERS] Re: possible row locking bug in 7.0.3 & 7.1
Next
From: Alessio Bragadini
Date:
Subject: 'Include' function in SQL scripts