Re: BUG: Former primary node might stuck when started as a standby

Поиск
Список
Период
Сортировка
От Aleksander Alekseev
Тема Re: BUG: Former primary node might stuck when started as a standby
Дата
Msg-id CAJ7c6TO-_=rfN0Mb1RrChmrQvLtXoWw9aDezwC9g48-Va3E2EQ@mail.gmail.com
обсуждение исходный текст
Ответ на Re: BUG: Former primary node might stuck when started as a standby  (Alexander Lakhin <exclusion@gmail.com>)
Ответы Re: BUG: Former primary node might stuck when started as a standby  (Alexander Lakhin <exclusion@gmail.com>)
Список 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 по дате отправления:

Предыдущее
От: Aleksander Alekseev
Дата:
Сообщение: Re: Remove unused fields in ReorderBufferTupleBuf
Следующее
От: David Rowley
Дата:
Сообщение: Re: Removing const-false IS NULL quals and redundant IS NOT NULL quals