Re: allow online change primary_conninfo

From: Sergei Kornilov <sk(at)zsrv(dot)org>
To: Andres Freund <andres(at)anarazel(dot)de>
Cc: Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com>, "michael(at)paquier(dot)xyz" <michael(at)paquier(dot)xyz>, "david(at)pgmasters(dot)net" <david(at)pgmasters(dot)net>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: allow online change primary_conninfo
Date: 2019-09-21 10:06:25
Message-ID: 41171569060385@myt5-b646bde4b8f3.qloud-c.yandex.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hello

Thank you for review! Can you please also check v4 version? v5 implements design suggested by Kyotaro Horiguchi-san, while v4 has another design. Which one do you prefer? Or are both wrong?

> I can't parse that comment. What does "skipping to starting" mean? I
> assume it's just about avoiding wal_retrieve_retry_interval, but I think
> the comment ought to be rephrased.

Design idea is to rewrite current state from working XLOG_FROM_STREAM to failed XLOG_FROM_ARCHIVE (without actually try this method on this iteration) and immediately go to next iteration to advance the state machine. Next iteration after failed archive recovery is walreceiver. So walreceiver will be stopped just before this lines and started on next iteration. Walreceiver will be restarted, we do not call restore_command

> Also, should we really check this before scanning for new timelines?

Hmm, on the next day... No, this is not really necessary.

> Why is it the right thing to change to XLOG_FROM_ARCHIVE when we're just
> restarting walreceiver? The server might unnecessarily get stuck in
> archive based recovery for a long time this way? It seems to me that
> we'd need to actually trigger RequestXLogStreaming() in this case.

I hope I clarified this in design idea description above.

Thank you!

regards, Sergei

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Amit Kapila 2019-09-21 12:31:18 Re: [HACKERS] Block level parallel vacuum
Previous Message David Fetter 2019-09-21 09:15:27 Re: WIP: Generic functions for Node types using generated metadata