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

Re: WIP fix proposal for bug #6123

From: Florian Pflug <fgp(at)phlo(dot)org>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Kevin Grittner <Kevin(dot)Grittner(at)wicourts(dot)gov>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: WIP fix proposal for bug #6123
Date: 2011-08-03 16:56:09
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
On Aug3, 2011, at 17:57 , Robert Haas wrote:
> On Wed, Aug 3, 2011 at 4:50 AM, Florian Pflug <fgp(at)phlo(dot)org> wrote:
>> The different between Kevin's original patch and my suggestion is, BTW,
>> that he made step (7) through an error while I suggested the error to
>> be thrown already at (4).
> I think Kevin's proposal is better, because AFAICS if the BEFORE
> UPDATE trigger returns NULL then we haven't got a problem; and we
> can't know that until we get to step 7.

Hm, not sure if I agree. A BEFORE trigger might decide to block an update,
and then take some action based on the assumption that the row is actually
unmodified (i.e., identical to the OLD value observed by the trigger).

To me, it still seems conceptionally cleaner to just decree that a row
must not be modified while BEFORE triggers are running, period.

This, BTW, also matches what Oracle does, only on a per-row instead of
per-table basis. Oracle AFAIR simply forbids touching of the table a BEFORE
trigger is attached to from within that trigger. (They even forbid SELECTS,
which is presumably because they don't have an equivalent of our per-row
command id, i.e. cannot ensure that such a SELECT sees the state the table
was in at the beginning of the statement)

best regards,
Florian Pflug

In response to


pgsql-hackers by date

Next:From: Kevin GrittnerDate: 2011-08-03 17:01:27
Subject: Re: WIP fix proposal for bug #6123
Previous:From: Pavan DeolaseeDate: 2011-08-03 16:33:49
Subject: Re: [GENERAL] Odd VACUUM behavior when it is expected to truncate last empty pages

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