Re: row filtering for logical replication
От | Amit Kapila |
---|---|
Тема | Re: row filtering for logical replication |
Дата | |
Msg-id | CAA4eK1Lpr7fE1z-aP6aCQbsS8c3CUdXqCqTuDR4KmBxR8VpG_Q@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: row filtering for logical replication (Alvaro Herrera <alvherre@alvh.no-ip.org>) |
Ответы |
Re: row filtering for logical replication
|
Список | pgsql-hackers |
On Tue, Apr 12, 2022 at 6:16 PM Alvaro Herrera <alvherre@alvh.no-ip.org> wrote: > > On 2022-Apr-12, Amit Kapila wrote: > > > It still has the same problem. The table can be dropped just before > > this message and the get_rel_name will return NULL and we don't expect > > that. > > Ugh, I forgot to change the errmsg() parts to use the new variable, > apologies. Fixed. > Thanks, this will work and fix the issue. I think this looks better than the current code, however, I am not sure if the handling for the concurrently dropped tables is better (both get_rel_relkind() and get_rel_name() can fail due to those reasons). I understand this won't fail because of the protection you have in the patch, so feel free to go ahead with this if you like this style better. -- With Regards, Amit Kapila.
В списке pgsql-hackers по дате отправления: