Re: BUG #13443: master will remove dead rows when hot standby(use slot) disconnect
От | Jeff Janes |
---|---|
Тема | Re: BUG #13443: master will remove dead rows when hot standby(use slot) disconnect |
Дата | |
Msg-id | CAMkU=1whqptkc5uyOQs15_DCK2qL_eVScZOUHbcichjwH-BwcQ@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: BUG #13443: master will remove dead rows when hot standby(use slot) disconnect (Andres Freund <andres@anarazel.de>) |
Ответы |
Re: BUG #13443: master will remove dead rows when hot
standby(use slot) disconnect
|
Список | pgsql-bugs |
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. > > 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
В списке pgsql-bugs по дате отправления:
Предыдущее
От: Andres FreundДата:
Сообщение: Re: BUG #13443: master will remove dead rows when hot standby(use slot) disconnect