Re: [HACKERS] [COMMITTERS] pgsql: Replication lag tracking for walsenders

Поиск
Список
Период
Сортировка
От Simon Riggs
Тема Re: [HACKERS] [COMMITTERS] pgsql: Replication lag tracking for walsenders
Дата
Msg-id CANP8+jJ8_NMHQ69C1h0ouBtC4xCni=0X5-eQ6vEyWONyaLU59A@mail.gmail.com
обсуждение исходный текст
Ответ на Re: [HACKERS] [COMMITTERS] pgsql: Replication lag tracking for walsenders  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
On 22 April 2017 at 16:41, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Thomas Munro <thomas.munro@enterprisedb.com> writes:
>> The assertion fails reliably for me, because standby2's reported write
>> LSN jumps backwards after the timeline changes: for example I see
>> 3020000 then 3028470 then 3020000 followed by a normal progression.
>> Surprisingly, 004_timeline_switch.pl reports success anyway.  I'm not
>> sure why the test fails sometimes on tern, but you can see that even
>> when it passed on tern the assertion had failed.
>
> Whoa.  This just turned into a much larger can of worms than I expected.
> How can it be that processes are getting assertion crashes and yet the
> test framework reports success anyway?  That's impossibly
> broken/unacceptable.

Agreed, thanks for fixing.

-- 
Simon Riggs                http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Simon Riggs
Дата:
Сообщение: Re: [HACKERS] StandbyRecoverPreparedTransactions recovers subtranslinks incorrectly
Следующее
От: Simon Riggs
Дата:
Сообщение: Re: [HACKERS] Statistics "dependency"