Re: BUG: Former primary node might stuck when started as a standby - Mailing list pgsql-hackers

From Aleksander Alekseev
Subject Re: BUG: Former primary node might stuck when started as a standby
Date
Msg-id CAJ7c6TO-_=rfN0Mb1RrChmrQvLtXoWw9aDezwC9g48-Va3E2EQ@mail.gmail.com
Whole thread Raw
In response to Re: BUG: Former primary node might stuck when started as a standby  (Alexander Lakhin <exclusion@gmail.com>)
Responses Re: BUG: Former primary node might stuck when started as a standby
List pgsql-hackers
Hi,

> But node1 knows that it's a standby now and it's expected to get all the
> WAL records from the primary, doesn't it?

Yes, but node1 doesn't know if it always was a standby or not. What if
node1 was always a standby, node2 was a primary, then node2 died and
node3 is a new primary. If node1 sees inconsistency  in the WAL
records, it should report it and stop doing anything, since it doesn't
has all the information needed to resolve the inconsistencies in all
the possible cases. Only DBA has this information.

> > It's been a while since I seriously played with replication, but if
> > memory serves, a proper way to switch node1 to a replica mode would be
> > to use pg_rewind on it first.
>
> Perhaps that's true generally, but as we can see, without the extra
> records replayed, this scenario works just fine. Moreover, existing tests
> rely on it, e.g., 009_twophase.pl or 012_subtransactions.pl (in fact, my
> research of the issue was initiated per a test failure).

I suggest focusing on particular flaky tests then and how to fix them.

-- 
Best regards,
Aleksander Alekseev



pgsql-hackers by date:

Previous
From: Aleksander Alekseev
Date:
Subject: Re: Remove unused fields in ReorderBufferTupleBuf
Next
From: David Rowley
Date:
Subject: Re: Removing const-false IS NULL quals and redundant IS NOT NULL quals