From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Philip Warner <pjw(at)rhyme(dot)com(dot)au> |
Cc: | pgsql-sql(at)postgresql(dot)org, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: [HACKERS] Re: possible row locking bug in 7.0.3 & 7.1 |
Date: | 2001-03-28 00:30:16 |
Message-ID: | 16115.985739416@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers pgsql-sql |
Philip Warner <pjw(at)rhyme(dot)com(dot)au> 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
From | Date | Subject | |
---|---|---|---|
Next Message | Vince Vielhaber | 2001-03-28 00:35:27 | Re: IANA registration |
Previous Message | Philip Warner | 2001-03-28 00:14:05 | Re: [HACKERS] Re: possible row locking bug in 7.0.3 & 7.1 |
From | Date | Subject | |
---|---|---|---|
Next Message | Forest Wilkinson | 2001-03-28 06:08:00 | Re: possible row locking bug in 7.0.3 & 7.1 |
Previous Message | Philip Warner | 2001-03-28 00:14:05 | Re: [HACKERS] Re: possible row locking bug in 7.0.3 & 7.1 |