Philip Warner wrote:
>
> At 19:14 29/03/01 -0800, Mikheev, Vadim wrote:
> >> >Reported problem is caused by bug (only one tuple version must be
> >> >returned by SELECT) and this is way to fix it.
> >> >
> >>
> >> 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?
>
I doubt if it's a bug of SELECT. Well what
'concurrent UPDATE then SELECT FOR UPDATE +
SELECT' return ?
regards,
Hiroshi Inoue
---------------------------(end of broadcast)---------------------------
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
- Re: [HACKERS] Re: [SQL] possible row locking bug in 7.0.3... Hiroshi Inoue
- RE: [HACKERS] Re: [SQL] possible row locking bug in ... Mikheev, Vadim
- RE: [HACKERS] Re: [SQL] possible row locking bug in ... Mikheev, Vadim
- RE: [HACKERS] Re: [SQL] possible row locking bug in ... Mikheev, Vadim
- Re: [HACKERS] Re: [SQL] possible row locking bug in ... Hiroshi Inoue
- Re: [HACKERS] Re: [SQL] possible row locking bug... Forest Wilkinson
- RE: [HACKERS] Re: [SQL] possible row locking bug in ... Mikheev, Vadim
- Re: [HACKERS] Re: [SQL] possible row locking bug... Hiroshi Inoue
- [HACKERS] Re: [SQL] possible row locking bug in 7.0.... Forest Wilkinson
- RE: [HACKERS] Re: [SQL] possible row locking bug in ... Mikheev, Vadim
- RE: [HACKERS] Re: [SQL] possible row locking bug in ... Mikheev, Vadim