On 4 March 2016 at 12:54, Michael Paquier <michael.paqu...@gmail.com> wrote:

> No objections from here as well for the feature itself. I am glad to
> see interest in extending the current infrastructure, and just
> wondering what kind of tests are going to show up.

The tests themselves really aren't that exciting. Create a slot, online
base-backup the node, start it in archive recovery, immediately fail over
to it or do some amount of writes first, do some more writes on it, then
read from the logical slot on the replica and prove that we can
successfully read the logical change change stream across the timeline

I'm now adding a module that goes a step further by exposing some functions
to SQL (test only, if you use it in production you're insane) to permit
creation of a logical slot on a replica and to advance that slot's
persistent data. It basically lets you advance the slot state on the
replica while it's in recovery so you can retain slot states copied with a
filesystem-level base backup and have the slots ready to use when you
promote the server.

I'm doing it to prove the concept of doing logical failover with an
extension and without full WAL-based failover slots in order to get the
timeline following for logical decoding patch committed separately to, and
prior to, failover slots. It's complicated enough that it needs a variety
of tests, but self-contained and non-intrusive enough to be a fairly easy
commit if it's shown to work well.

 Craig Ringer                   http://www.2ndQuadrant.com/
 PostgreSQL Development, 24x7 Support, Training & Services

Reply via email to