Re: speed up a logical replica setup
От | Peter Eisentraut |
---|---|
Тема | Re: speed up a logical replica setup |
Дата | |
Msg-id | d3ea49ed-1994-4803-8fdd-727bd39d03c9@eisentraut.org обсуждение исходный текст |
Ответ на | Re: speed up a logical replica setup (Amit Kapila <amit.kapila16@gmail.com>) |
Список | pgsql-hackers |
On 19.03.24 08:05, Amit Kapila wrote: > On Mon, Mar 18, 2024 at 7:22 PM Peter Eisentraut <peter@eisentraut.org> wrote: >> >> In check_subscriber(): All these permissions checks seem problematic >> to me. We shouldn't reimplement our own copy of the server's >> permission checks. The server can check the permissions. And if the >> permission checking in the server ever changes, then we have >> inconsistencies to take care of. Also, the error messages "permission >> denied" are inappropriate, because we are not doing the actual thing. >> Maybe we want to do a dry-run for the benefit of the user, but then we >> should do the actual thing, like try to create a replication slot, or >> whatever. But I would rather just remove all this, it seems too >> problematic. >> > > If we remove all the checks then there is a possibility that we can > fail later while creating the actual subscription. For example, if > there are not sufficient max_replication_slots, then it is bound to > fail in the later steps which would be a costlier affair because by > that time the standby would have been promoted and the user won't have > any way to move forward but to re-create standby and then use this > tool again. I think here the patch tries to mimic pg_upgrade style > checks where we do some pre-checks. I think checking for required parameter settings is fine. My concern is with the code before that, that does pg_has_role/has_database_privilege/has_function_privilege.
В списке pgsql-hackers по дате отправления: