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 switch. 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
