Re: [HACKERS] [COMMITTERS] pgsql: Replication lag tracking for walsenders
От | Tom Lane |
---|---|
Тема | Re: [HACKERS] [COMMITTERS] pgsql: Replication lag tracking for walsenders |
Дата | |
Msg-id | 300.1492927294@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: [HACKERS] [COMMITTERS] pgsql: Replication lag tracking for walsenders (Thomas Munro <thomas.munro@enterprisedb.com>) |
Ответы |
Re: [HACKERS] [COMMITTERS] pgsql: Replication lag tracking for walsenders
|
Список | pgsql-hackers |
Thomas Munro <thomas.munro@enterprisedb.com> writes: > On Sun, Apr 23, 2017 at 3:41 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote: >> As for this patch itself, is it reasonable to try to assert that the >> timeline has in fact changed? > The protocol doesn't include the timeline in reply messages, so it's > not clear how the upstream server would know what timeline the standby > thinks it's dealing with in any given reply message. The sending > server has its own idea of the current timeline but it's not in sync > with the stream of incoming replies. Fair enough. But I'd still like an explanation of why only about half of the population is showing a failure here. Seems like every machine should be seeing the LSN as moving backwards in this test. So (a) why aren't they all failing, and (b) should we change the test to make sure every platform sees that happening? regards, tom lane
В списке pgsql-hackers по дате отправления: