Re: Add primary keys to system catalogs

From: Julien Rouhaud <rjuju123(at)gmail(dot)com>
To: Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Joel Jacobson <joel(at)compiler(dot)org>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Add primary keys to system catalogs
Date: 2021-02-02 14:54:30
Message-ID: CAOBaU_bZPAfmxqEGzQUwJPVsDtwFK-E9Jorapb-4YgUMDtq65g@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, Feb 2, 2021 at 6:49 PM Peter Eisentraut
<peter(dot)eisentraut(at)2ndquadrant(dot)com> wrote:
>
> I do wonder, however, under what circumstances code would be put into a
> situation where it would add the exact same dependency again, and also
> under what circumstances it would add a dependency between the same
> objects but a different deptype, and how that would work during
> recursive deletion. Now that we have the refobjversion column, the
> presence of duplicate dependencies might be even more dubious. I think
> that could be worth analyzing.

There's at least dependencies from indexes to pg_class (underlying
table) and pg_collation that can be entirely duplicated (if the same
column and/or collation is used in both key and predicate for
instance), and this was the case before refobjversion was introduced.

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Noah Misch 2021-02-02 15:14:16 Race between KeepFileRestoredFromArchive() and restartpoint
Previous Message Victor Yegorov 2021-02-02 14:27:56 Re: New IndexAM API controlling index vacuum strategies