REASSIGN OWNED vs. relisshared dep on !relisshared - Mailing list pgsql-hackers

From Noah Misch
Subject REASSIGN OWNED vs. relisshared dep on !relisshared
Date
Msg-id 20260710192533.4f.noahmisch@microsoft.com
Whole thread
Responses Re: REASSIGN OWNED vs. relisshared dep on !relisshared
List pgsql-hackers
v19 commit 8185bb5 added field pg_subscription.subserver, and v20 commit
a5918fd added field pg_subscription.subconflictlogrelid.  Each involves a
dependency link from the relisshared pg_subscription to a !relisshared
catalog.  REASSIGN OWNED, if run in a database other than
pg_subscription.subdbid, wrongly interprets those fields relative to the
current database.  This causes an error or opens an unrelated object.

Perhaps one could fix this by having REASSIGN OWNED process only
pg_subscription rows where subdbid is the current database.  Already, one must
run REASSIGN OWNED in each database for ordinary db-local objects like tables.
From a user's perspective, REASSIGN OWNED would reach subscriptions like it
reaches tables.

I'm nervous that we'll have other reasons to regret letting a shared object
depend on a non-shared object, but I've not come up with anything else
concrete.

Ops 4.8 wrote the attached test cases.  (The subserver test patch has tests
for some other behaviors, which I'll post about elsewhere.)

Attachment

pgsql-hackers by date:

Previous
From: Melanie Plageman
Date:
Subject: Re: Why clearing the VM doesn't require registering vm buffer in wal record
Next
From: Noah Misch
Date:
Subject: CREATE SUBSCRIPTION ... SERVER vs. pg_dump, etc.