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

From Jeff Davis
Subject Re: REASSIGN OWNED vs. relisshared dep on !relisshared
Date
Msg-id f629d0d3f74413e48a53bdf5b334b215c68545fb.camel@j-davis.com
Whole thread
In response to REASSIGN OWNED vs. relisshared dep on !relisshared  (Noah Misch <noah@leadboat.com>)
Responses Re: REASSIGN OWNED vs. relisshared dep on !relisshared
Re: REASSIGN OWNED vs. relisshared dep on !relisshared
List 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




pgsql-hackers by date:

Previous
From: surya poondla
Date:
Subject: Re: Fix races conditions in DropRole() and GrantRole()
Next
From: Jeff Davis
Date:
Subject: Re: REASSIGN OWNED vs. relisshared dep on !relisshared