On 14/06/13 07:38, Fujii Masao wrote:
On Wed, Jun 12, 2013 at 12:55 PM, Mark Kirkwood
<mark.kirkw...@catalyst.net.nz> wrote:
On 12/06/13 13:15, Stephen Frost wrote:
* Fujii Masao (masao.fu...@gmail.com) wrote:
The attached patch fixes this problem. It just changes walsender so that
it
waits for all the outstanding WAL records to be replicated to the standby
before closing the replication connection.
Seems like a good idea to me.. Rather surprised that we're not doing
this already, to be honest.
Yeah +1 from here too. This would make clean switchovers for (typically)
testing scenarios a lot less complex and resource intensive (rebuilding of
the old master as a slave when you know it is ok is despairing on a huge
db).
On the related note (but not actually to do with this patch),
clarifying/expanding the docs about the various methods for standby
promotion:
1/ trigger file creation
2/ pg_ctl promote
3/ renaming/removing recovery.conf
and the differences between them would be great. For instance I only
recently realized that method 3) means the promoted standby does not start a
new timeline (incidentally - could this be an option to pg_ctl promote)
which is very useful for (again) controlled/clean switchovers.
In 9.3, you no longer need to worry about the increment of timeline
after the promotion because the standby can automatically follow
the timeline switch.
Regards,
Yes - and that will be awesome. Nice work!
However for those systems still on 9.1/9.2for the time being, some
clarification of the details/differences uisg promotion via the 1) - 3)
would be useful I think.
Note I'm not demanding that you do it - I just happened to be thinking
about this when I saw your patch, so though I'd mention it (I've seen
some brief discussion about this before, but nothing concrete came out
of that in terms of documentation additions).
If folks are keen, I'm willing to attempt to find a suitable place in
the docs to add a discussion about 1) - 3) above. However I was kinda
hoping that someone who knows all the details would... fro instance I've
skimmed the code and note that the system "knows" when it is promoted
via trigger file vs pg_ctl... but as to what if any differences that
makes to the resulting actions (other than removing the trigger file) -
I am not clear on.
Cheers
Mark
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
