On 2015-06-16 10:00:13 -0700, Jeff Janes wrote:
> On Mon, Jun 15, 2015 at 5:52 PM, Michael Paquier <michael.paquier@gmail.com>
> wrote:
> I haven't looked at the code, or paid much attention when the feature went
> in. From the docs, I thought that is what would happen as well. But
> experimentally, that only happens if hot_standby_feedback is on. I get the
> same behavior
> on 9.4.4 and on 9.5devel.
>
> postgresql.conf:
>
> wal_level = logical
> max_wal_senders = 3
> max_replication_slots = 3
> hot_standby = on
> hot_standby_feedback = off ## toggled on standby over course of
> experiment
> port=5433 ### on standby only. default on master
>
> on master:
> SELECT * FROM pg_create_physical_replication_slot('node_a_slot');
>
> recovery.conf:
> standby_mode = 'on'
> primary_conninfo = 'port=5432 user=jjanes'
> primary_slot_name = 'node_a_slot'
>
> I repeat Digoal's example, only don't crash the standby.
>
> I leave the stand-by connected, with a client sitting in a repeatable read
> transaction, and then delete the tuples on the master side. Vacuum will
> quickly reclaim the tuples, and then after 30s the stand-by session gets
> disconnect due to conflict. When I toggle hot_standby_feedback on, then it
> behaves as expected, with the master never cleaning up the deleted tuples.
It's expected that we only hold up the xmin horizon on the primary via
slots if hot_standby_feedback is enabled. It seemed - and still seems -
like a bad idea to force hs_feedback to on if slots are used, using it
is much more expensive than just retaining WAL. Do you disagree?
Where do the docs imply the contrary?
Greetings,
Andres Freund