> 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
---------------------------(end of broadcast)---------------------------
TIP 4: Don't 'kill -9' the postmaster
- [HACKERS] Re: [SQL] possible row locking bug in 7.0.3 &am... Tom Lane
- Re: [HACKERS] Re: [SQL] possible row locking bug in ... Philip Warner
- Re: [HACKERS] Re: [SQL] possible row locking bug in ... Tom Lane
- Re: [HACKERS] Re: [SQL] possible row locking bug... Hiroshi Inoue
- RE: [HACKERS] Re: [SQL] possible row locking bug in ... Mikheev, Vadim
- RE: [HACKERS] Re: [SQL] possible row locking bug... Philip Warner
- Re: [HACKERS] Re: [SQL] possible row locking bug in ... Hiroshi Inoue
- Re: [HACKERS] Re: [SQL] possible row locking bug... Philip Warner
- RE: [HACKERS] Re: [SQL] possible row locking bug in ... Philip Warner
- RE: [HACKERS] Re: [SQL] possible row locking bug in ... Tom Lane
- 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... Hiroshi Inoue
- Re: [HACKERS] Re: [SQL] possible row locking bug in ... Forest Wilkinson
- RE: [HACKERS] Re: [SQL] possible row locking bug in ... Mikheev, Vadim
