Problem Description
This error may happen in a read replica when, after initiating a select, some necessary rows for the select have been modified or deleted on the primary and the primary is vacuumed (generally by the autovacuum process) to clean up the corresponding changed tables.
If this occurs, the same action will be performed against the replica and the query canceled.
Solution
To mitigate this issue, we recommend increasing the default value of the following parameters:
max_standby_archive_delaymax_standby_streaming_delay
The first one is useful when the replication is based on log-shipping methodology and the latter one is when the replication is based on streaming methodology.
BigAnimal HA Cluster read-only connections
In this case, we advise increasing the default value (30 seconds) of max_standby_streaming_delay
This will let the replica delay the application of WAL records for the amount of time specified by that parameter.
BigAnimal Faraway replica
In this case, we advise increasing the default value (30 seconds) of max_standby_archive_delay
This will let the faraway replica delay the application of WAL files for the amount of time specified by that parameter.
If you want to learn more about this issue you can read the postgresql documentation page about that by clicking the link below.
Standby conflicts