On Tue, Jun 16, 2015 at 4:30 AM, Jeff Janes <jeff.janes@gmail.com> wrote:
> On Mon, Jun 15, 2015 at 2:05 AM, <digoal@126.com> wrote:
>> http://www.postgresql.org/docs/devel/static/warm-standby.html#STREAMING-REPLICATION
>>
>> 25.2.6. Replication Slots
>> 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.
>>
>> In my test, master will remove rows when standby disconnect.
>
>
> I can't reproduce this. In my hands when the standby crashes, tuples on the
> master are not removed until either that slot is destroyed on the master, or
> until the standby reconnects.
Yep.
> Can you show us all the settings changes you have made to postgresql.conf
> and recovery.conf, and to the replication slots table?
Yes, perhaps the standby has already acknowledged the dead tuples
before you shut it down.
> One potential doc bug I see is that the it seems to imply that replication
> slots replaces the need for hot_standby_feedback, when it fact it must be
> used in conjunction with it. Do you have hot_standby_feedback turned on in
> the standby?
As far as I recall, using replication slots implies that the
RecentGlobalXmin horizon is updated to guarantee the presence of
tuples on the standby once it reconnects. Perhaps I am missing
something?
--
Michael