Re: BUG #13443: master will remove dead rows when hot standby(use slot) disconnect

On Wed, Jun 17, 2015 at 4:58 AM, Jeff Janes <jeff.janes@gmail.com> wrote:
> On Tue, Jun 16, 2015 at 12:21 PM, Andres Freund <andres@anarazel.de> wrote:
>>
>> 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?
>
>
> No disagreement.  I don't know much about the expensive, and don't have an
> opinion one
> way or the other.

Agreement from here as well. So my recollection of elements on the
matter was incorrect. Thanks for the clarification.
--
Michael