Re: REASSIGN OWNED vs. relisshared dep on !relisshared

From: Jeff Davis <pgsql(at)j-davis(dot)com>
To: Noah Misch <noah(at)leadboat(dot)com>
Cc: akapila(at)postgresql(dot)org, dilipbalaut(at)gmail(dot)com, nisha(dot)moond412(at)gmail(dot)com, pgsql-hackers(at)postgresql(dot)org
Subject: Re: REASSIGN OWNED vs. relisshared dep on !relisshared
Date: 2026-07-10 22:11:16
Message-ID: f629d0d3f74413e48a53bdf5b334b215c68545fb.camel@j-davis.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Fri, 2026-07-10 at 12:25 -0700, Noah Misch wrote:
> Perhaps one could fix this by having REASSIGN OWNED process only
> pg_subscription rows where subdbid is the current database.

That was my first thought, as well. I will look into it.

> 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.

That's a reasonable concern. We discussed it here:

https://www.postgresql.org/message-id/CAA4eK1LyHvRoNzZPpPQqo7a%3D5Wov8F-7%2BKDduy-9ymcRm%3DBatg%40mail.gmail.com

Though the root of the problem might be that pg_subscription is shared
in the first place.

Perhaps we should just not record the dependency on the foreign server
at all, and if someone drops it, then the drop succeeds and the
connection fails later. That would be more like what would happen if
you revoke privileges, which also isn't tracked by the dependency
mechanism but has a similar result.

Regards,
Jeff Davis

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Jeff Davis 2026-07-10 22:17:58 Re: REASSIGN OWNED vs. relisshared dep on !relisshared
Previous Message surya poondla 2026-07-10 21:42:26 Re: Fix races conditions in DropRole() and GrantRole()