From: | Heikki Linnakangas <hlinnaka(at)iki(dot)fi> |
---|---|
To: | Michael Paquier <michael(dot)paquier(at)gmail(dot)com>, Michael Banck <michael(dot)banck(at)credativ(dot)de> |
Cc: | PostgreSQL mailing lists <pgsql-hackers(at)postgresql(dot)org>, Christoph Berg <christoph(dot)berg(at)credativ(dot)de> |
Subject: | Re: pg_rewind hangs if --source-server is used and syncrep is enabled |
Date: | 2016-10-06 10:37:16 |
Message-ID: | 3505e694-b661-2abd-8967-7acdf9df60a1@iki.fi |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 10/06/2016 02:24 AM, Michael Paquier wrote:
> On Wed, Oct 5, 2016 at 11:53 PM, Michael Banck
> <michael(dot)banck(at)credativ(dot)de> wrote:
>> 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.
Committed, thanks! I moved the call to where we establish the
connection, that felt slightly more natural.
- Heikki
From | Date | Subject | |
---|---|---|---|
Next Message | Amit Langote | 2016-10-06 11:17:47 | Re: postgres_fdw : altering foreign table not invalidating prepare statement execution plan. |
Previous Message | Simon Riggs | 2016-10-06 09:56:34 | Re: autonomous transactions |