Re: Outdated replication protocol error?
От | Jeff Davis |
---|---|
Тема | Re: Outdated replication protocol error? |
Дата | |
Msg-id | dcef9eaae8fc6d8f6f260ff3d051c197cdd29a8e.camel@j-davis.com обсуждение исходный текст |
Ответ на | Re: Outdated replication protocol error? (Andres Freund <andres@anarazel.de>) |
Ответы |
Re: Outdated replication protocol error?
|
Список | pgsql-hackers |
On Wed, 2021-06-16 at 16:17 -0700, Andres Freund wrote: > I think we should explicitly compute the current timeline before > using > ThisTimelineID. E.g. in StartReplication() call a new version of > GetFlushRecPtr() that also returns the current timeline id. I think all we need to do is follow the pattern in IdentifySystem() by calling: am_cascading_walsender = RecoveryInProgress(); first. There are three cases: 1. If the server was a primary the last time RecoveryInProgress() was called, and it's still a primary, then it returns false immediately. ThisTimeLineID should be set properly already. 2. If the server was a secondary the last time RecoveryInProgress() was called, and now it's a primary, then it updates ThisTimeLineID in InitXLOGAccess() and returns false. 3. If the server was a secondary the last time, and is still a secondary, then it returns true. Then, StartReplication() will call GetStandbyFlushRecPtr(), which will update ThisTimeLineID. It was confusing to me for a while because I was trying to sort out whether am_cascading_walsender and/or ThisTimeLineID could be out of date, and how that would result in not updating ThisTimeLineID; and also why there was a difference between IdentifySystem() and StartReplication(). Simple patch attached. I didn't test it yet, but wanted to post my analysis. Regards, Jeff Davis
Вложения
В списке pgsql-hackers по дате отправления: