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
Re: row filtering for logical replication |
Список | 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 по дате отправления: