Re: TAP / recovery-test fs-level backups, psql enhancements etc
От | Craig Ringer |
---|---|
Тема | Re: TAP / recovery-test fs-level backups, psql enhancements etc |
Дата | |
Msg-id | CAMsr+YEmaHE8VBXzbOyZVY4-yj4wVcA0pMn+bKCxEzTk00oFLw@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: TAP / recovery-test fs-level backups, psql enhancements etc (Michael Paquier <michael.paquier@gmail.com>) |
Список | pgsql-hackers |
On 4 March 2016 at 12:54, Michael Paquier <michael.paquier@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.
В списке pgsql-hackers по дате отправления: