On Wed, Jun 3, 2020 at 1:07 PM Laurenz Albe <laurenz.albe@cybertec.at> wrote:
>
> I'm seeing the following at a customer site:
>
> SELECT confl_tablespace, confl_lock, confl_snapshot, confl_bufferpin, confl_deadlock
> FROM pg_stat_database_conflicts
> WHERE datname = 'something' \gx
>
> -[ RECORD 1 ]----+------
> confl_tablespace | 0
> confl_lock | 0
> confl_snapshot | 84990
> confl_bufferpin | 0
> confl_deadlock | 0
>
> SHOW hot_standby_feedback;
>
> hot_standby_feedback
> ----------------------
> on
> (1 row)
>
> This is PostgreSQL 11.7, the standby didn't disconnect from the primary, and
> the number of replication conflicts is growing.
>
> I had thought that "hot_standby_feedback = on" would get rid of such
> conflicts.
>
> In the code I see a lot of call sites for ResolveRecoveryConflictWithSnapshot,
> so it is hard for me to track this down. Does anybody know what could cause
> these replication conflicts?
One of the frequent causes is the lock acquired by (auto)vacuum when
truncating the trailing empty blocks, maybe you can correlate your
conflicts with autovacuum activity?
