From: | Hiroshi Inoue <Inoue(at)tpf(dot)co(dot)jp> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Philip Warner <pjw(at)rhyme(dot)com(dot)au>, 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 06:19:05 |
Message-ID: | 3AC18259.C5A8B0A9@tpf.co.jp |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers pgsql-sql |
Tom Lane wrote:
>
> 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.
Is it the MVCC's restriction that each query inside a function
must use the same snapshot ?
> As I've opined before, the whole EvalPlanQual mechanism
> strikes me as essentially bogus in any case...
>
How would you change it ? UPDATE/SELECT FOR UPDATE have to
SELECT/UPDATE the latest tuples. I don't think of any simple
way for 'SELECT FOR UPDATE' to have the same visibility as
simple SELECT.
regards,
Hiroshi Inoue
From | Date | Subject | |
---|---|---|---|
Next Message | Marcin Kowalski | 2001-03-28 07:37:21 | Re: pg_dump potential bug |
Previous Message | Tatsuo Ishii | 2001-03-28 06:11:59 | Re: Re: Call for platforms |
From | Date | Subject | |
---|---|---|---|
Next Message | Marcin Kowalski | 2001-03-28 07:37:21 | Re: pg_dump potential bug |
Previous Message | Tom Lane | 2001-03-28 06:11:08 | Re: possible row locking bug in 7.0.3 & 7.1 |