Re: BUG #15631: Generated as identity field in a temporary table withon commit drop corrupts system catalogs
От | Peter Eisentraut |
---|---|
Тема | Re: BUG #15631: Generated as identity field in a temporary table withon commit drop corrupts system catalogs |
Дата | |
Msg-id | 0bc96c3e-8a3f-414f-8ba7-f7f95a787d48@2ndquadrant.com обсуждение исходный текст |
Ответ на | 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 with on commit drop corrupts system catalogs
|
Список | pgsql-bugs |
On 2019-02-13 05:41, Michael Paquier wrote: > 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. What is the general coding principle here? "You need an CCI $WHEN"? -- Peter Eisentraut http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
В списке pgsql-bugs по дате отправления: