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

From: Michael Paquier <michael(dot)paquier(at)gmail(dot)com>
To: Jeff Janes <jeff(dot)janes(at)gmail(dot)com>
Cc: Andres Freund <andres(at)anarazel(dot)de>, 德哥 <digoal(at)126(dot)com>, Pg Bugs <pgsql-bugs(at)postgresql(dot)org>
Subject: Re: BUG #13443: master will remove dead rows when hot standby(use slot) disconnect
Date: 2015-06-17 03:45:16
Message-ID: CAB7nPqTAb3+V38XW4UZFC57Zf+WFBq-YmJXqmMsC_kTT+DzUZQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

On Wed, Jun 17, 2015 at 4:58 AM, Jeff Janes <jeff(dot)janes(at)gmail(dot)com> wrote:
> On Tue, Jun 16, 2015 at 12:21 PM, Andres Freund <andres(at)anarazel(dot)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(dot)paquier(at)gmail(dot)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

In response to

Browse pgsql-bugs by date

  From Date Subject
Next Message Michael Paquier 2015-06-17 04:08:33 Re: BUG #13446: pg_dump fails with large tuples
Previous Message digoal 2015-06-17 02:17:07 BUG #13449: Auto type cast (int -> numeric) non-reasonable, will case performance problem