It turned out that the problem is not caused by dead rows removing. The problem is that autovacuum process truncates empty pages at the end of the relation and takes AccessExclusiveLock on the relation. WAL receiver process, in turn, tries to take this log while replaying WAL segment with corresponding standby_redo command and fails because of the long-running query holding AccessShareLock on standby. Since max_standby_streaming_delay setting is set to -1 WAL receiver waits until query is finished and as a result the replication lag is increasing. There is a patch proposed in 2018/11 commit fest but it is not even reviewed yet: https://commitfest.postgresql.org/20/1683/ On Tue, Nov 13, 2018 at 10:53 PM Rui DeSousa <rui@xxxxxxxxxxxxx> wrote: > > > > > On Nov 13, 2018, at 4:18 AM, Andrey Zhidenkov <andrey.zhidenkov@xxxxxxxxx> wrote: > > > > Yes, they are streaming replicas. Could you please tell me how to > > check xmin of the replica in pg_stat_activity? I didn't get the point. > > > > select pid > , usename > , application_name > , backend_start > , backend_xmin > , state > from pg_stat_replication > ; > > select pid > , state > , backend_xid > , backend_xmin > , backend_type > , backend_start > from pg_stat_activity > where backend_xmin is not null > ; > > Vacuum will use the xmin to determine if a record is still needed or not thus I just wanted to make sure the replica are sending that information to the master. > > What is the exact error message? > -- - With best regards, Andrey Zhidenkov
