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

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.

>
> Where do the docs imply the contrary?
>

"Replication slots provide an automated way to ensure that the master does
not remove WAL segments until they have been received by all standbys, and
that the master does not remove rows which could cause a recovery conflict
even when the standby is disconnected."

To me, "automated way to ensure" implies you don't need to also set other
things, that it is automatic.

Perhaps a change to "Replication slots provide an automated way to ensure
that the master does not remove WAL segments until they have been received
by all standbys. With hs_feedback turned on, it also ensures that the
master does not remove rows which could cause a recovery conflict even when
the standby is disconnected."

Also "Similarly, hot_standby_feedback and vacuum_defer_cleanup_age provide
protection against relevant rows being removed by vacuum, but the former
provides no protection during any time period when the standby is not
connected, and the latter often needs to be set to a high value to provide
adequate protection. Replication slots overcome these disadvantages."

It reads to me like slots is being offered as an alternative, not an
adjunct, to hs_feedback. It overcomes the disadvantages for the two things
in dissimilar ways: one by bridging the connectivity gap; and the other by
making the use of the setting unnecessary in the first place. Having the
dissimilar things presented in parallel was unintuitive to me. You can
read it correctly, provided you already know what the correct reading is,
but it doesn't really provide much illumination to the learner. But if the
previous paragraph were explicit, then this would be fine.

Jeff