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

From: Hiroshi Inoue <Inoue(at)tpf(dot)co(dot)jp>
To: "Mikheev, Vadim" <vmikheev(at)SECTORBASE(dot)COM>
Cc: Philip Warner <pjw(at)rhyme(dot)com(dot)au>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-sql(at)postgresql(dot)org, pgsql-hackers(at)postgresql(dot)org
Subject: Re: [HACKERS] Re: possible row locking bug in 7.0.3 & 7.1
Date: 2001-03-30 10:15:22
Message-ID: 3AC45CBA.8CDC3213@tpf.co.jp
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers 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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Mathijs Brands 2001-03-30 10:17:01 Re: Re: [PORTS] pgmonitor and Solaris
Previous Message Pete Forman 2001-03-30 10:07:25 Re: Re: [PORTS] pgmonitor and Solaris

Browse pgsql-sql by date

  From Date Subject
Next Message Koen Antonissen 2001-03-30 11:52:28 Max Size of a text field
Previous Message Koen Antonissen 2001-03-30 09:58:16 Max Size of a text field