On Mon, Sep 4, 2017 at 4:34 PM, <i.kartys...@postgrespro.ru> wrote: > Our clients complain about this issue and therefore I want to raise the > discussion and suggest several solutions to this problem: > > I. Why does PG use Fatal when Error is enough to release lock that rises > lock conflict? > "If (RecoveryConflictPending && DoingCommandRead)" > > II. Do we really need to truncate the table on hot standby exactly at the > same time when truncate on master occurs? > > In my case conflict happens when the autovacuum truncates table tbl1 on > master while backend on replica is performing a long transaction involving > the same table tbl1. This happens because truncate takes an > AccessExclusiveLock. To tackle this issue we have several options: > > 1. We can postpone the truncate on the master until all the replicas have > finished their transactions (in this case, feedback requests to the master > should be sent frequently) > Patch 1 > vacuum_lazy_truncate.patch > > 2. Maybe there is an option somehow not to send AccessExclusiveLock and not > to truncate table on the replica right away. We could try to wait a little > and truncate tbl1 on replica again. >
Can max_standby_streaming_delay help in this situation (point number - 2)? -- With Regards, Amit Kapila. EnterpriseDB: http://www.enterprisedb.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
