On Fri, Feb 12, 2021 at 2:49 PM Amit Kapila <amit.kapil...@gmail.com> wrote: > > On Fri, Feb 12, 2021 at 10:08 AM Ajin Cherian <itsa...@gmail.com> wrote: > > > > On Fri, Feb 12, 2021 at 2:46 PM Amit Kapila <amit.kapil...@gmail.com> wrote: > > > > > > > > Thanks, I have pushed the patch but getting one failure: > > > https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=thorntail&dt=2021-02-12%2002%3A28%3A12 > > > > > > The reason seems to be that we are trying to connect and > > > max_wal_senders is set to zero. I think we can write this without > > > trying to connect. The attached patch fixes the problem for me. What > > > do you think? > > > > Verified this with installcheck and modified configuration to have > > wal_level = minimal and max_wal_senders = 0. > > Tests passed. The changes look good to me. > > > > Thanks, I have pushed the fix and the latest run of 'thorntail' has passed.
I got the following WARNING message from a logical replication apply worker: WARNING: relcache reference leak: relation "pg_subscription_rel" not closed The cause of this is that GetSubscriptionRelState() doesn't close the relation in SUBREL_STATE_UNKNOWN case. It seems that commit ce0fdbfe9 forgot to close it. I've attached the patch to fix this issue. Here is a reproducible step: 1. On both publisher and subscriber: create table test (a int primary key); 2. On publisher: create publication test_pub for table test; 3. On subscriber: create subscription test_sub connection 'dbname=postgres' publication test_pub"; -- wait until table sync finished drop table test; create table test (a int primary key); >From this point, you will get the WARNING message when doing insert/update/delete/truncate to 'test' table on the publisher. Regards, -- Masahiko Sawada EDB: https://www.enterprisedb.com/
fix_relcache_leak.patch
Description: Binary data