From: | Michael Paquier <michael(at)paquier(dot)xyz> |
---|---|
To: | Sergei Kornilov <sk(at)zsrv(dot)org> |
Cc: | Andres Freund <andres(at)anarazel(dot)de>, Kyotaro HORIGUCHI <horiguchi(dot)kyotaro(at)lab(dot)ntt(dot)co(dot)jp>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: allow online change primary_conninfo |
Date: | 2019-02-18 03:19:54 |
Message-ID: | 20190218031954.GB15532@paquier.xyz |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Mon, Feb 18, 2019 at 12:06:05AM +0300, Sergei Kornilov wrote:
> Ok. This was not mentioned before Michael response
> yesterday. restore_command is much faster compared to database
> restart [...]
The startup process would not switch back to streaming with archiving
enabled until it has consumed all the segments available. I recall
David Steele mentioning me that a perl command invocation can take
easily 100ms. On a system which generates more than 10 segments per
segment, you can guess what happens.. I think that this argument is a
non-starter if we want to make the WAL receiver a maximum available.
>> That'd still switch to a different method, something we do not want...
>
> Ok, do not want means we do not want. Will try change behavior.
Thanks Sergei for considering it. The code paths touched are
sensitive, so we had better be careful here.
--
Michael
From | Date | Subject | |
---|---|---|---|
Next Message | Michael Paquier | 2019-02-18 03:24:35 | Re: Progress reporting for pg_verify_checksums |
Previous Message | Amit Langote | 2019-02-18 02:49:31 | Re: 2019-03 CF Summary / Review - Tranche #2 |