Thread: Re: Re: [SQL] 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
> 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
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 |/
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
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