On 25.04.2013 17:55, Kyotaro HORIGUCHI wrote:
Hmm. I think that I caught the tail of the problem..
Script with small change reproduced the situation for me.
Can you share the modified script, please?
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.
I'm not sure I understand what the problem is, though. When the standby
opens the bogus, recycled, file in pg_xlog, it will notice that the
header is incorrect, and retry reading the file from the archive.
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..
Perhaps, but it should nevertheless not get confused by recycled segments.
- Heikki
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
