Re: BUG #15631: Generated as identity field in a temporary table with on commit drop corrupts system catalogs

From: Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Michael Paquier <michael(at)paquier(dot)xyz>, dnsl48(at)gmail(dot)com, pgsql-bugs(at)lists(dot)postgresql(dot)org
Subject: Re: BUG #15631: Generated as identity field in a temporary table with on commit drop corrupts system catalogs
Date: 2019-02-15 16:03:29
Message-ID: 99401209-fb88-036d-c93f-dbe5211a091a@2ndquadrant.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

On 2019-02-15 15:43, Tom Lane wrote:
> Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com> writes:
>> What is the general coding principle here? "You need an CCI $WHEN"?
>
> The general principle is "there should be a CCI after each independent
> set of data/catalog changes". You don't typically need CCI between
> the primitive actions of a single DDL statement like CREATE SEQUENCE,
> because you know that those actions are independent and don't look at
> each others' output. But you need one at the end, in case whatever
> happens next should be able to see the results of the statement.

Yeah, I'm OK on that, but that's not really the problem here. This is
not a case where a later step in a complex DDL command needs to see what
an earlier step did. This is about that something later in the
transaction needs to see what happened earlier in the transaction. This
does not seem to be the job of each individual DDL command; they don't
know what someone later might want to look at. Otherwise many DDL
command implementations are lacking this CCI. I think the CCI should be
more like at the end of ProcessUtility().

--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Doug Safreno 2019-02-15 22:35:23 Re: Bug: Deferred FKey Check Happening on Double Update, Not Single
Previous Message John Klann 2019-02-15 15:37:31 Re: BUG #15636: PostgreSQL 11.1 pg_basebackup backup to a CIFS destination throws fsync error at end of backup