From: Tom Lane <tgl@sss.pgh.pa.us>
To: Thomas Munro <thomas.munro@enterprisedb.com>
Cc: Michael Paquier <michael.paquier@gmail.com>
Cc: phb07@apra.asso.fr, Andrew Gierth <rhodiumtoad@postgresql.org>
Cc: PostgreSQL mailing lists <pgsql-bugs@postgresql.org>
Cc: Kevin Grittner <kgrittn@gmail.com>
Subject: Re: BUG #14808: V10-beta4, backend abort
Date: Mon, 11 Sep 2017 20:53:00 -0400
Message-ID: <13342.1505177580@sss.pgh.pa.us> (raw)
In-Reply-To: <CAEepm=2P2a4hO8dED+1g0emRUbWFmc85Ahug4YbbrO0GYwYkiA@mail.gmail.com>
References: <20170909064853.25630.12825@wrigleys.postgresql.org>
<CAB7nPqRBE35VOtvU=VfV66sqvV5L+raGi8R64WBD3jjS3G4HZA@mail.gmail.com>
<3702.1504976930@sss.pgh.pa.us>
<9324.1504983594@sss.pgh.pa.us>
<25326.1505070173@sss.pgh.pa.us>
<CAEepm=0rNhRe8Zjf46H__au+KrAYktbefpNyFHVqn9ZfFyKV_Q@mail.gmail.com>
<14016.1505135324@sss.pgh.pa.us>
<8201.1505149431@sss.pgh.pa.us>
<CAEepm=2P2a4hO8dED+1g0emRUbWFmc85Ahug4YbbrO0GYwYkiA@mail.gmail.com>
List-Unsubscribe: <mailto:majordomo@postgresql.org?body=unsub%20pgsql-bugs>
Thomas Munro <thomas.munro@enterprisedb.com> writes:
> Aside from the RI case, the other user visible change in behaviour
> will be for statements that update the same table via multiple
> ModifyTable nodes (wCTEs). Our regression test has:
> with wcte as (insert into table1 values (42))
> insert into table2 values ('hello world');
> ... which demonstrates the fix for the original complaint that table1
> and table2 earlier tried to use the same transition table (and
> crashed). A new variant inserting into table1 twice would show the
> difference. Today we get:
> postgres=# with wcte as (insert into table1 values (42))
> insert into table1 values (43);
> NOTICE: trigger = table1_trig, new table = (43,)
> NOTICE: trigger = table1_trig, new table = (42,)
> INSERT 0 1
> Presumably with your change there will be a single transition table
> for inserts into table, holding both (42,) and (43,). But will we
> fire the trigger once or twice?
Not necessarily. That would be true only if we allow the WCTE to share
trigger context with the outer query, which I think it does not today.
I've not checked the code, but presumably if we fire the trigger twice
right now, that means there are separate trigger contexts, ie somebody
is calling AfterTriggerBeginQuery/AfterTriggerEndQuery around the WCTE.
If not, maybe we could make it do so. OTOH, looking at the text of
the spec, I think it's darn hard to justify the behavior shown above.
The reason that the RI case would share trigger context with the outer
query is that we'd *not* call AfterTriggerBeginQuery/AfterTriggerEndQuery
around the RI query, which would be driven by the same skip_trigger
logic that exists today.
>> This seems like rather a mess to implement. I wonder whether I'm
>> reading it right, and whether other DBMSes actually implement it
>> like that.
> I guess the alternative is storing extra per-tuple metadata,
> transferring more work to the reader.
I really don't want any more per-tuple state. Adding the TCS link
was costly enough in terms of how big the tuple queue storage is.
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-bugs@postgresql.org
Cc: tgl@sss.pgh.pa.us, thomas.munro@enterprisedb.com, michael.paquier@gmail.com, rhodiumtoad@postgresql.org, kgrittn@gmail.com
Subject: Re: BUG #14808: V10-beta4, backend abort
In-Reply-To: <13342.1505177580@sss.pgh.pa.us>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox