Re: running logical replication as the subscription owner - Mailing list pgsql-hackers

From Jelte Fennema
Subject Re: running logical replication as the subscription owner
Date
Msg-id CAGECzQRq4DHDfmCWHmQrG8D2Q9xmqqXXdPc7-x32RUwRuu_Wdw@mail.gmail.com
Whole thread Raw
In response to Re: running logical replication as the subscription owner  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: running logical replication as the subscription owner  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
> I don't think it makes sense for this patch to run around and try to
> adjust all of those other pages. We have to pick between doing it this
> way (and thus being inconsistent with what we do elsewhere) or taking
> that logic out (and taking our chances that something will break for
> some users). I'm OK with either of those, but I'm not OK with going
> and changing the way this works in all of the other cases first and
> only then coming back to this problem. This problem is WAY more
> important than fiddling with the details of how
> SECURITY_RESTRICTED_OPERATION is applied.

Yes, I totally agree. I now realise that wasn't clear at all from the wording in my previous email. I'm fine with both behaviours. I mainly meant that if we actually think the new behaviour is better (which honestly I'm not convinced of yet), then some follow up patch would probably be good. I definitely don't want to block this patch on any of that though. Both behaviors would be vastly better than the current one in my opinion. So if others wanted the behaviour in your patch, I'm completely fine with that. 

> Yeah, if we stick with the current approach we should probably add
> tests for that stuff.

Even if we don't, we should still have tests showing that the security restrictions that we intend to put in place actually do their job.

pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: Transparent column encryption
Next
From: Corey Huinker
Date:
Subject: Re: Make ON_ERROR_STOP stop on shell script failure