Re: BUG #15631: Generated as identity field in a temporary tablewith on commit drop corrupts system catalogs - Mailing list pgsql-bugs

From Michael Paquier
Subject Re: BUG #15631: Generated as identity field in a temporary tablewith on commit drop corrupts system catalogs
Date
Msg-id 20190213044104.GE5746@paquier.xyz
Whole thread Raw
In response to Re: BUG #15631: Generated as identity field in a temporary tablewith on commit drop corrupts system catalogs  (Michael Paquier <michael@paquier.xyz>)
Responses Re: BUG #15631: Generated as identity field in a temporary tablewith on commit drop corrupts system catalogs  (Michael Paquier <michael@paquier.xyz>)
Re: BUG #15631: Generated as identity field in a temporary table withon commit drop corrupts system catalogs  (Peter Eisentraut <peter.eisentraut@2ndquadrant.com>)
Re: BUG #15631: Generated as identity field in a temporary table withon commit drop corrupts system catalogs  (Peter Eisentraut <peter.eisentraut@2ndquadrant.com>)
List pgsql-bugs
On Wed, Feb 13, 2019 at 11:38:17AM +0900, Michael Paquier wrote:
> Agreed.  I don't think that it is the correct logic to put an
> after-the-fact CCI just before executing any drop or truncate actions.
> It should happen after the creation of the new object so as it becomes
> correctly visible within the transaction.

The problem comes from process_owned_by() in sequence.c which has
added in v10 some handling for internal dependencies in the case of an
identity sequence, and the dependency link between the sequence and
its relation is added there.

Another thing I was wondering is if we should add the CCI directly to
recordMultipleDependencies() for internal dependencies, still it seems
to me that it would be an overkill as some dependency registrers may
do the CCI by themselves after adding the pg_depend link and doing
some other operations, so I discarded the idea.

The patch attached solves the problem, for consistency I would suggest
doing the CCI even for auto dependencies.
--
Michael

Attachment

pgsql-bugs by date:

Previous
From: Amit Langote
Date:
Subject: Re: 'update returning *' returns 0 columns instead of empty row with2 columns when (i) no rows updated and (ii) when applied to a partitionedtable with sub-partition
Next
From: "Guy Rouillier"
Date:
Subject: Re[2]: BUG #15626: Incorrect version number shown in BigSQL installation