Re: row filtering for logical replication

Поиск
Список
Период
Сортировка
От Alvaro Herrera
Тема Re: row filtering for logical replication
Дата
Msg-id 202204121131.ennkfguxxu2e@alvherre.pgsql
обсуждение исходный текст
Ответ на Re: row filtering for logical replication  (Amit Kapila <amit.kapila16@gmail.com>)
Ответы Re: row filtering for logical replication  (Alvaro Herrera <alvherre@alvh.no-ip.org>)
Re: row filtering for logical replication  (Amit Kapila <amit.kapila16@gmail.com>)
Список pgsql-hackers
On 2022-Apr-12, Amit Kapila wrote:

> On Tue, Apr 12, 2022 at 3:45 PM Amit Kapila <amit.kapila16@gmail.com> wrote:

> > We don't have a lock on the relation, so if it gets dropped
> > concurrently, it won't behave sanely. For example, get_rel_name() will
> > return NULL which seems incorrect to me.

Oh, oops ... a trap for the unwary?  Anyway, yes, we can disregard the
entry when get_rel_name returns null.  Amended patch attached.

> > I am not sure about this as well because you will instead do a RELOID
> > cache lookup even when there is no row filter or column list.

I guess my assumption is that the pg_class cache is typically more
populated than other relcaches, but that's unsubstantiated.  I'm not
sure if we have any way to tell which one is the more common case.
Anyway, let's do it the way you already had it.

> It seems to me that we have a similar coding pattern in ExecGrant_Relation().

Not sure what you mean?  In that function, when the syscache lookup
returns NULL, an error is raised.

-- 
Álvaro Herrera         PostgreSQL Developer  —  https://www.EnterpriseDB.com/
"El número de instalaciones de UNIX se ha elevado a 10,
y se espera que este número aumente" (UPM, 1972)

Вложения

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

Предыдущее
От: Amit Kapila
Дата:
Сообщение: Re: typos
Следующее
От: Alvaro Herrera
Дата:
Сообщение: Re: row filtering for logical replication