Yes, consider using Repmgr.
> On 08-Aug-2018, at 3:20 AM, Richard Schmidt
> wrote:
>
> We think we have found our missing step. We needed to do an ordered shutdown
> of the original primary before promoting the standby
> I.e.
>
> >1. Make some changes to the A (the primary) and check that th
> On Aug 4, 2018, at 13:50, Michael Paquier wrote:
>
> Hm?
The specific situation is if pg_rewind is attached to the target before the
forced post-recovery checkpoint completes, the target can be corrupted:
https://www.postgresql.org/message-id/ece3b665-e9dd-43ff-b6a6-734e74352...@
On Sat, Aug 04, 2018 at 07:54:36AM -0700, Christophe Pettus wrote:
> Would having pg_rewind do a checkpoint on the source actually cause
> anything to break, as opposed to a delay while the checkpoint
> completes?
Users relying only on streaming without archives would be impacted as
potentially tw
> On Aug 4, 2018, at 06:13, Michael Paquier wrote:
>
> Well, since its creation we have the tool behave this way. I am not
> sure either that we can have pg_rewind create a checkpoint on the source
> node each time a rewind is done, as it may not be necessary, and it
> would enforce WAL segmen
On Sat, Aug 04, 2018 at 04:59:45AM -0700, Andres Freund wrote:
> On 2018-08-04 10:54:22 +0100, Simon Riggs wrote:
>> pg_rewind doesn't work correctly. Documenting a workaround doesn't change
>> that.
>
> Especially because most people will only understand this after they've
> been hit, as test sc
On 2018-08-04 10:54:22 +0100, Simon Riggs wrote:
> On 4 August 2018 at 07:56, Michael Paquier wrote:
> >> Sounds like we should write a pending timeline change to the control
> >> file and have pg_rewind check that instead.
> >>
> >> I'd call this a timing bug, not a doc issue.
> >
> > Well, havin
On 4 August 2018 at 07:56, Michael Paquier wrote:
> On Sat, Aug 04, 2018 at 07:44:59AM +0100, Simon Riggs wrote:
>> I think the problem is that writing the online checkpoint is deferred
>> after promotion, so this is a timing issue that probably doesn't show
>> in our regression tests.
>
> Somewha
On Sat, Aug 04, 2018 at 07:44:59AM +0100, Simon Riggs wrote:
> I think the problem is that writing the online checkpoint is deferred
> after promotion, so this is a timing issue that probably doesn't show
> in our regression tests.
Somewhat. It is a performance improvement of 9.3 to let the start
On 3 August 2018 at 21:59, Michael Paquier wrote:
> On Wed, Aug 01, 2018 at 09:09:30PM +, Richard Schmidt wrote:
>> Our procedure that runs on machine A and B is as follows:
>>
>> 1. Build new databases on A and B, and configure A as Primary and B
>> as Standby databases.
>> 2. Make so
On Wed, Aug 01, 2018 at 09:09:30PM +, Richard Schmidt wrote:
> Our procedure that runs on machine A and B is as follows:
>
> 1. Build new databases on A and B, and configure A as Primary and B
> as Standby databases.
> 2. Make some changes to the A (the primary) and check that they ar
Whenever you do switch-over, postgres-wal creates a new timeline, which
simplifies managing PITR process.
During switch-over(promoting B as master) you had some delta records written to
A, that’s where it causes this timeline issue.
Now since A had some delta records, it can’t replicate from B
11 matches
Mail list logo
