| From: | Jaime Casanova <jaime(dot)casanova(at)2ndquadrant(dot)com> |
|---|---|
| To: | Stephen Frost <sfrost(at)snowman(dot)net> |
| Cc: | cyberdemn(at)gmail(dot)com, sk(at)zsrv(dot)org, emre(at)hasegeli(dot)com, Pg Hackers <pgsql-hackers(at)postgresql(dot)org>, berge(at)trivini(dot)no, ben(at)gurkan(dot)in, raimund(dot)schlichtiger(at)innogames(dot)com, Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com>, bernhard(dot)schrader(at)innogames(dot)com, Simon Riggs <simon(at)2ndquadrant(dot)com>, vik(at)2ndquadrant(dot)fr |
| Subject: | Re: Standby trying "restore_command" before local WAL |
| Date: | 2018-08-06 17:07:49 |
| Message-ID: | CAJGNTeMdTFnZvraEti=6h56MAYGxjiT9pdAA4gPb0YuFn6yFMw@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Mon, 6 Aug 2018 at 11:01, Stephen Frost <sfrost(at)snowman(dot)net> wrote:
>
> > What about the following cases?
> > 1. replica host crashed, and in pg_wal we have a few thousands WAL files.
>
> If this is the case then the replica was very far behind on replay,
> presumably, and in some of those cases rebuilding the replica might
> very well be faster than replaying all of that WAL. This case does
> sound like it should be alright though.
>
it could also be a delayed standby, and in that case we will have in
the replica lots of valid -delayed apply on porpouse, not on master
anymore- WALs, restarting from archive in that case is a poor
solution...
--
Jaime Casanova www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Stephen Frost | 2018-08-06 17:12:46 | Re: Standby trying "restore_command" before local WAL |
| Previous Message | Michael Paquier | 2018-08-06 16:58:16 | Improve behavior of concurrent TRUNCATE |