Re: Outdated replication protocol error?
Jeff Davis <pgsql@j-davis.com>
From: Jeff Davis <pgsql@j-davis.com>
To: Andres Freund <andres@anarazel.de>
Cc: Fujii Masao <masao.fujii@oss.nttdata.com>, pgsql-hackers@postgresql.org,
Simon Riggs <simon@2ndquadrant.com>, Craig Ringer
<craig.ringer@enterprisedb.com>
Date: 2021-06-18T01:13:57Z
Lists: pgsql-hackers
Attachments
- fix-start-replication-identify-system.diff (text/x-patch) patch
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
Commits
-
Eliminate replication protocol error related to IDENTIFY_SYSTEM.
- 8e7811e952b4 15.0 landed
-
Ensure ThisTimeLineID is valid before START_REPLICATION
- 5ee2197767f6 10.0 cited