On Wed, Oct 5, 2016 at 11:53 PM, Michael Banck
<michael.banck@credativ.de> wrote:
> On Wed, Oct 05, 2016 at 04:39:39PM +0200, Michael Banck wrote:
>> To the user, the last thing printed is "need to copy XXXX MB [...]". If
>> the user cancels the pg_rewind command with ^C, the backend keeps
>> hanging around even in --dry-run mode. That won't hurt too much as it
>> does not seem to block future pg_rewind runs after synchronous_commit
>> has been set to a different value, but looks surprising to me.
Oops.
>> Not sure whether pg_rewind could error out gracefully without hanging in
>> this case,
>
> My colleague Christoph Berg pointed out that pg_rewind could just set
> synchronous_commit = local before creating the temporary table, which
> indeed works, proof-of-concept patch attached
Even synchronous_commit = off would not matter much, and we could just
use that for performance reasons. The temporary table used in this
context is just used to track the delta chunks of blocks, so this
solution sounds better to me. I'll patch 9.4's pg_rewind similarly to
what is decided here, and we could as well use an extra PQexec call to
bring more clarity for the code, now an extra round-trip could be a
big deal where network lag matters, but compared to the COPY chunks
sent out that would not matter much I guess. I am just posting another
version, and added a CF entry to not lose track of it:
https://commitfest.postgresql.org/11/811/
--
Michael
