Skip site navigation (1) Skip section navigation (2)

Re: [HACKERS] Re: possible row locking bug in 7.0.3 & 7.1

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 (view raw or flat)
Thread:
Lists: pgsql-hackerspgsql-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

In response to

Responses

pgsql-hackers by date

Next:From: Vince VielhaberDate: 2001-03-28 00:35:27
Subject: Re: IANA registration
Previous:From: Philip WarnerDate: 2001-03-28 00:14:05
Subject: Re: [HACKERS] Re: possible row locking bug in 7.0.3 & 7.1

pgsql-sql by date

Next:From: Forest WilkinsonDate: 2001-03-28 06:08:00
Subject: Re: possible row locking bug in 7.0.3 & 7.1
Previous:From: Philip WarnerDate: 2001-03-28 00:14:05
Subject: Re: [HACKERS] Re: possible row locking bug in 7.0.3 & 7.1

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group