Philip Warner <[EMAIL PROTECTED]> writes: >> The workaround for Forest is to make the final SELECT be a SELECT FOR >> UPDATE, so that it's playing by the same rules as the earlier commands. > Eek. Does this seem good to you? I did call it a workaround ;-) I don't think that we dare try to make any basic changes in MVCC for 7.1 at this late hour, so Forest is going to have to live with that answer for awhile. But I would like to see a cleaner answer in future releases. As I've opined before, the whole EvalPlanQual mechanism strikes me as essentially bogus in any case... regards, tom lane ---------------------------(end of broadcast)--------------------------- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
- [HACKERS] Re: [SQL] possible row locking bug in 7.0.3 &... Tom Lane
- Re: [HACKERS] Re: [SQL] possible row locking bug in 7.... Philip Warner
- Re: [HACKERS] Re: [SQL] possible row locking bug in 7.... Tom Lane
- Re: [HACKERS] Re: [SQL] possible row locking bug i... Hiroshi Inoue
- RE: [HACKERS] Re: [SQL] possible row locking bug in 7.... Mikheev, Vadim
- RE: [HACKERS] Re: [SQL] possible row locking bug i... Philip Warner
- Re: [HACKERS] Re: [SQL] possible row locking bug in 7.... Hiroshi Inoue
- Re: [HACKERS] Re: [SQL] possible row locking bug i... Philip Warner
- RE: [HACKERS] Re: [SQL] possible row locking bug in 7.... Philip Warner
- Re: [HACKERS] Re: [SQL] possible row locking bug in 7.... Tom Lane
- RE: [HACKERS] Re: [SQL] possible row locking bug in 7.... Mikheev, Vadim
- RE: [HACKERS] Re: [SQL] possible row locking bug in 7.... Mikheev, Vadim
- Re: [HACKERS] Re: [SQL] possible row locking bug i... Hiroshi Inoue