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
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 |