Heikki Linnakangas <heikki.linnakangas@enterprisedb.com> writes:
> I'm sorry, but I still don't understand the use case you're envisioning. How
> many standbys are there? What are you trying to achieve with synchronous
> replication over what asynchronous offers?
Sorry if I've been unclear, I read loads of message then tried to pick
up the right one to answer, and obviously missed to spell out some
context.
My concern starts with only 1 standby, and is in fact 2 questions:
- Why o why you wouldn't be able to fix your sync setup in the master as soon as there's a standby doing a base
backup?
- when do you start considering the standby as a candidate to your sync rep requirements?
Lots of the discussion we're having are taking as an implicit that the
answer is "as soon as you know about its existence, that must be at the
pg_start_backup() point". I claim that's incorrect, and you can't ask
the master to wait forever until the standby is in sync. All the more
because there's a window with wal_keep_segments here too, so the sync
might never happen.
To solve that problem, I propose managing current state of the
standby.
That means auto registration of any standby, and feedback loop at more stages, and some protocol arbitrage for the
standbyto be able to say "I'm this far actually" so that the master can know how to consider it, rather than just
demoteit while live.
One you have a clear list of possible states for a standby, and can
decide on what errors are meaning in terms of transitions in the state
machine, you're able to decide when wait forever is an option and when
you should ignore it or refuse any side-effect transaction commit.
And you can offer an option to guarantee the wait-forever behavior only
when it makes sense, rather than trying to catch your own tail as soon
as a standby is added in the mix, with the proposals I've read on how
you can't even restart the master at this point.
Regards,
--
Dimitri Fontaine
http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support