> 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