Re: Failing start-up archive recovery at Standby mode in PG9.2.4 - Mailing list pgsql-hackers

From Kyotaro HORIGUCHI
Subject Re: Failing start-up archive recovery at Standby mode in PG9.2.4
Date
Msg-id CAM103DtF=MatrzGH2rAD82Y3RsxKfYLXBBpCJ3TTKFK3=UN_kg@mail.gmail.com
Whole thread Raw
In response to Re: Failing start-up archive recovery at Standby mode in PG9.2.4  (Amit Langote <amitlangote09@gmail.com>)
Responses Re: Failing start-up archive recovery at Standby mode in PG9.2.4
Re: Failing start-up archive recovery at Standby mode in PG9.2.4
List pgsql-hackers
Hmm. I think that I caught the tail of the problem..

Script with small change reproduced the situation for me.

The latest standby uses 3 as its TLI after the history file
0..3.history which could get from the archive. So the WAL files
recycled on this standby will have the TLI=3.
Nevertheless the LSN of the segment recycled on standby is on the
TLI=2 in the master, the standby makes the first request for each
segment with that LSN but TLI = 3 to the master because the standby
runs on recoveryTargetTLI=3. The master reasonably doesn't have it and
finally the standby finds that wrong WAL file in its pg_xlog directory
before the second request with TLI=2 would be made.

In conclusion, the standby should name the recycled WAL segment using
the same TLI for the LSN on the master. Or should never recycle WAL
files..

regards,

--
Kyotaro Horiguchi



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Proposal to add --single-row to psql
Next
From: Andrew Dunstan
Date:
Subject: Re: Proposal to add --single-row to psql