Re: Re: [COMMITTERS] pgsql: Make standby server continuously retry restoring the next WAL - Mailing list pgsql-hackers

From Dimitri Fontaine
Subject Re: Re: [COMMITTERS] pgsql: Make standby server continuously retry restoring the next WAL
Date
Msg-id 877hqjc2kk.fsf@hi-media-techno.com
Whole thread Raw
In response to Re: Re: [COMMITTERS] pgsql: Make standby server continuously retry restoring the next WAL  (Simon Riggs <simon@2ndQuadrant.com>)
Responses Re: Re: [COMMITTERS] pgsql: Make standby server continuously retry restoring the next WAL
List pgsql-hackers
Simon Riggs <simon@2ndQuadrant.com> writes:
> If you were running pg_standby as the restore_command then this error
> wouldn't happen. So you need to explain why running pg_standby cannot
> solve your problem and why we must fix it by replicating code that has
> previously existed elsewhere.

Let me try.

pg_standby will not let the server get back to streaming replication
mode once it's done with driving the replay of all the WAL files
available in the archive, but will have the server sits there waiting
for the next file.

The way we want that is implemented now is to have the server switch
back and forth between replaying from the archive and streaming from the
master. So we want the server to restore from the archive the same way
pg_standby used to, except that if the archive does not contain the next
WAL files, we want to get back to streaming.

And the archive reading will resume at next network glitch.

I think it's the reasonning, I hope it explains what you see happening.
-- 
dim


pgsql-hackers by date:

Previous
From: Andrew Chernow
Date:
Subject: Re: TCP keepalive support for libpq
Next
From: Marko Tiikkaja
Date:
Subject: Re: Writeable CTEs and empty relations