Re: allow online change primary_conninfo - Mailing list pgsql-hackers

From Sergei Kornilov
Subject Re: allow online change primary_conninfo
Date
Msg-id 41171569060385@myt5-b646bde4b8f3.qloud-c.yandex.net
Whole thread Raw
In response to Re: allow online change primary_conninfo  (Andres Freund <andres@anarazel.de>)
Responses Re: allow online change primary_conninfo
List pgsql-hackers
Hello

Thank you for review! Can you please also check v4 version? v5 implements design suggested by Kyotaro Horiguchi-san,
whilev4 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
thismethod on this iteration) and immediately go to next iteration to advance the state machine. Next iteration after
failedarchive 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



pgsql-hackers by date:

Previous
From: David Fetter
Date:
Subject: Re: WIP: Generic functions for Node types using generated metadata
Next
From: Amit Kapila
Date:
Subject: Re: [HACKERS] Block level parallel vacuum