Re: pg_upgrade (and recovery) pitfalls

2018-08-17 Thread Stephen Frost
Greetings, * PO (gunnar.bl...@pro-open.de) wrote: > Stephen Frost – Thu, 16. August 2018 19:00 > > * PO (gunnar.bl...@pro-open.de) wrote: > > > - why does a recovery, based on a recovery.conf that points to a reachable > > primary (which obviously communicates its own timeline), still look for >

Re: pg_upgrade (and recovery) pitfalls

2018-08-17 Thread PO
Stephen Frost – Thu, 16. August 2018 19:00 > Greetings, I salute you, Stephen! TL;DR: I blundered by not spotting an easter egg of my predecessors. > * PO (gunnar.bl...@pro-open.de) wrote: > > Consider the following scenario/setup: > > - 4 DB servers in 2 DCs > > - 1 primary (in DC1) > > - 1 sy

Re: pg_upgrade (and recovery) pitfalls

2018-08-16 Thread Stephen Frost
Greetings, * PO (gunnar.bl...@pro-open.de) wrote: > Consider the following scenario/setup: > - 4 DB servers in 2 DCs > - 1 primary (in DC1) > - 1 sync secondary (in other DC) > - 2 async secondaries (distributed over DCs) I'm a bit surprised that you're ok with the latency imposed by using