Re: Non-superuser subscription owners

Поиск
Список
Период
Сортировка
От Jeff Davis
Тема Re: Non-superuser subscription owners
Дата
Msg-id 785e8b8ab06f123cf754862557bd3171aeba4d65.camel@j-davis.com
обсуждение исходный текст
Ответ на Re: Non-superuser subscription owners  (Amit Kapila <amit.kapila16@gmail.com>)
Ответы Re: Non-superuser subscription owners
Список pgsql-hackers
On Mon, 2021-11-29 at 09:43 +0530, Amit Kapila wrote:
> The first reason is that way it would be consistent with what we can
> see while doing the operations from the backend.

Logical replication is not interactive, so it doesn't seem quite the
same.

If you have a long running INSERT INTO SELECT or COPY FROM, the
permission checks just happen at the beginning. As a user, it wouldn't
surprise me if logical replication was similar.

> operation. Another reason is to make behavior predictable as users
> can
> always expect when exactly the privilege change will be reflected and
> it won't depend on the number of changes in the transaction.

This patch does detect ownership changes more quickly (at the
transaction boundary) than the current code (only when it reloads for
some other reason). Transaction boundary seems like a reasonable time
to detect the change to me.

Detecting faster might be nice, but I don't have a strong opinion about
it and I don't see why it necessarily needs to happen before this patch
goes in.

Also, do you think the cost of doing maybe_reread_subscription() per-
tuple instead of per-transaction would be detectable? If we lock
ourselves into semantics that detect changes quickly, it will be harder
to optimize the per-tuple path later.

Regards,
    Jeff Davis





В списке pgsql-hackers по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: Windows: Wrong error message at connection termination
Следующее
От: Tom Lane
Дата:
Сообщение: Re: Lots of memory allocated when reassigning Large Objects