On Sat, Feb 1, 2014 at 6:09 PM, Andres Freund <and...@2ndquadrant.com> wrote: > On 2014-02-01 16:47:47 +0900, Fujii Masao wrote: >> On Sat, Feb 1, 2014 at 12:50 PM, Robert Haas <rh...@postgresql.org> wrote: >> > Introduce replication slots. >> > >> > Replication slots are a crash-safe data structure which can be created >> > on either a master or a standby to prevent premature removal of >> > write-ahead log segments needed by a standby, as well as (with >> > hot_standby_feedback=on) pruning of tuples whose removal would cause >> > replication conflicts. Slots have some advantages over existing >> > techniques, as explained in the documentation. >> > >> > In a few places, we refer to the type of replication slots introduced >> > by this patch as "physical" slots, because forthcoming patches for >> > logical decoding will also have slots, but with somewhat different >> > properties. >> >> This patch changed basebackup.c so that it skips pg_replslot. It's OK >> to skip all files in that directory, but an empty pg_replslot must be >> included in the backup. Otherwise we cannot start PostgreSQL from >> the backup taken via pg_basebackup. Attached patch fixes this problem. > > That's a pretty fair point. Not sure how that could escape my > notice. The patch does look sane to me. > > I wonder if we additionally should add code to recreate pg_replslot on > startup, similar to pg_xlog?
Similar to pg_xlog/archive_status, not pg_xlog? That might be an option. But I'm not inclined to do that for now. The fact that the essential directory like pg_replslot doesn't exist indicates the symptom of something strange. And, changing that way might prevent us from detecting such symptom. BTW, we should add the setting of primary_slotname into recovery.conf.sample? Regards, -- Fujii Masao -- Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-committers
