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?


----------------------------------------------------------------
Philip Warner                    |     __---_____
Albatross Consulting Pty. Ltd.   |----/       -  \
(A.B.N. 75 008 659 498)          |          /(@)   ______---_
Tel: (+61) 0500 83 82 81         |                 _________  \
Fax: (+61) 0500 83 82 82         |                 ___________ |
Http://www.rhyme.com.au          |                /           \|
                                 |    --________--
PGP key available upon request,  |  /
and from pgp5.ai.mit.edu:11371   |/

Fri, 30 Mar 2001 14:02:28 +1000
Philip Warner <pjw@rhyme.com.au>
RE: [HACKERS] Re: possible row locking bug in 7.0.3 & 7.1
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

Fri, 30 Mar 2001 13:16:16 +0900
Hiroshi Inoue <Inoue@tpf.co.jp>
Re: [HACKERS] Re: possible row locking bug in 7.0.3 & 7.1
At 13:16 30/03/01 +0900, Hiroshi Inoue wrote:
>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. 

No idea where the bug is, but SELECT should never return two versions of
the *same* row.


>'Well what
>'concurrent UPDATE then SELECT FOR UPDATE +
>SELECT' return ?

No idea, maybe Vadim or Tom can help?



----------------------------------------------------------------
Philip Warner                    |     __---_____
Albatross Consulting Pty. Ltd.   |----/       -  \
(A.B.N. 75 008 659 498)          |          /(@)   ______---_
Tel: (+61) 0500 83 82 81         |                 _________  \
Fax: (+61) 0500 83 82 82         |                 ___________ |
Http://www.rhyme.com.au          |                /           \|
                                 |    --________--
PGP key available upon request,  |  /
and from pgp5.ai.mit.edu:11371   |/

Fri, 30 Mar 2001 16:14:54 +1000
Philip Warner <pjw@rhyme.com.au>
Re: [HACKERS] Re: possible row locking bug in 7.0.3 & 7.1
> Just looked in heapam.c - I can fix it in two hours.
> The question is - should we do this now?

This scares the hell out of me.

I do NOT think we should be making quick-hack changes in fundamental
system semantics at this point of the release cycle.

The problem went unnoticed for two full release cycles --- therefore,
it can wait another cycle for a fix that has been considered, reviewed,
and tested.  Let's not risk making things worse by releasing a new
behavior we might find out is also wrong.

			regards, tom lane

Fri, 30 Mar 2001 01:15:15 -0500
Tom Lane <tgl@sss.pgh.pa.us>
Re: [HACKERS] Re: possible row locking bug in 7.0.3 & 7.1 
On Thursday 29 March 2001 22:15, Tom Lane wrote:
> > Just looked in heapam.c - I can fix it in two hours.
> > The question is - should we do this now?
>
> This scares the hell out of me.
>
> I do NOT think we should be making quick-hack changes in fundamental
> system semantics at this point of the release cycle.

Although I'm the one who is being bit by this bug, I tend to agree.

> The problem went unnoticed for two full release cycles 

I first reported the problem on 25 September 2000, on the pgsql-sql list, 
message subject "SQL functions not locking properly?"  I was using 7.0.2 at 
the time.  Also, I seem to remember that a problem of this nature bit me in 
6.5.x as well.

> it can wait another cycle for a fix that has been considered, reviewed,
> and tested.  Let's not risk making things worse by releasing a new
> behavior we might find out is also wrong.

Good point.  How long is the next cycle likely to take?

Forest

Fri, 30 Mar 2001 15:47:22 -0800
Forest Wilkinson <fspam@home.com>
Re: [HACKERS] Re: possible row locking bug in 7.0.3 & 7.1
Forest Wilkinson <fspam@home.com> writes:
> Good point.  How long is the next cycle likely to take?

Good question.  I'd like to say 4 to 6 months, but that was how long 7.1
was supposed to take, and we're pushing a year now.

What might make the most sense is to develop and test a fix in the early
part of the 7.2 development cycle, and then back-patch it into a 7.1.x
release perhaps 2 or 3 months from now.

			regards, tom lane

Fri, 30 Mar 2001 19:01:27 -0500
Tom Lane <tgl@sss.pgh.pa.us>
Re: [HACKERS] Re: possible row locking bug in 7.0.3 & 7.1 
I see postgres 7.1.1 is out now.  Was the fix for this problem included in 
the new release?


On Thursday 29 March 2001 20:02, 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?

Wed, 16 May 2001 19:18:51 -0700
Forest Wilkinson <fspam@home.com>
Re: [HACKERS] Re: possible row locking bug in 7.0.3 & 7.1