Thread: pgsql: At promotion, archive last segment from old timeline with .parti
pgsql: At promotion, archive last segment from old timeline with .parti
From
Heikki Linnakangas
Date:
At promotion, archive last segment from old timeline with .partial suffix. Previously, we would archive the possible-incomplete WAL segment with its normal filename, but that causes trouble if the server owning that timeline is still running, and tries to archive the same segment later. It's not nice for the standby to trip up the master's archival like that. And it's pretty confusing, anyway, to have an incomplete segment in the archive that's indistinguishable from a normal, complete segment. To avoid such confusion, add a .partial suffix to the file. Or to be more precise, make a copy of the old segment under the .partial suffix, and archive that instead of the original file. pg_receivexlog also uses the .partial suffix for the same purpose, to tell apart incompletely streamed files from complete ones. There is no automatic mechanism to use the .partial files at recovery, so they will go unused, unless the administrator manually copies to them to the pg_xlog directory (and removes the .partial suffix). Recovery won't normally need the WAL - when recovering to the new timeline, it will find the same WAL on the first segment on the new timeline instead - but it nevertheless feels better to archive the file with the .partial suffix, for debugging purposes if nothing else. Branch ------ master Details ------- http://git.postgresql.org/pg/commitdiff/de7688442f5aaa03da60416a6aa3474738718803 Modified Files -------------- src/backend/access/transam/xlog.c | 133 +++++++++++++++++++++++++++--------- src/include/access/xlog_internal.h | 5 ++ src/include/postmaster/pgarch.h | 2 +- 3 files changed, 107 insertions(+), 33 deletions(-)
On Sat, May 9, 2015 at 4:07 AM, Heikki Linnakangas <heikki.linnakangas@iki.fi> wrote: > At promotion, archive last segment from old timeline with .partial suffix. > > Previously, we would archive the possible-incomplete WAL segment with its > normal filename, but that causes trouble if the server owning that timeline > is still running, and tries to archive the same segment later. It's not nice > for the standby to trip up the master's archival like that. And it's pretty > confusing, anyway, to have an incomplete segment in the archive that's > indistinguishable from a normal, complete segment. > > To avoid such confusion, add a .partial suffix to the file. Or to be more > precise, make a copy of the old segment under the .partial suffix, and > archive that instead of the original file. pg_receivexlog also uses the > .partial suffix for the same purpose, to tell apart incompletely streamed > files from complete ones. > > There is no automatic mechanism to use the .partial files at recovery, so > they will go unused, unless the administrator manually copies to them to > the pg_xlog directory (and removes the .partial suffix). Recovery won't > normally need the WAL - when recovering to the new timeline, it will find > the same WAL on the first segment on the new timeline instead - but it > nevertheless feels better to archive the file with the .partial suffix, for > debugging purposes if nothing else. Doesn't this change break the case where we want to PITR to the recovery target location in the last partial WAL file with the old timeline? In this case, that partial WAL file needs to be read and replayed. But since the suffix of its filename is .partial, unless DBA gets rid of the suffix, the WAL file cannot be restored and PITR would fail. No? Regards, -- Fujii Masao
Re: pgsql: At promotion, archive last segment from old timeline with .parti
From
Peter Eisentraut
Date:
On 5/8/15 3:07 PM, Heikki Linnakangas wrote: > At promotion, archive last segment from old timeline with .partial suffix. There appears to be a mixup here: + char origpath[MAXPGPATH]; + char partialfname[MAXFNAMELEN]; + char partialpath[MAXPGPATH]; + + XLogFilePath(origpath, EndOfLogTLI, endLogSegNo); + snprintf(partialfname, MAXPGPATH, "%s.partial", origfname); + snprintf(partialpath, MAXPGPATH, "%s.partial", origpath); Some compilers are complaining that the snprintf(partialfname, ...) could overflow.