Currently, if you run pg_xlogdump with -f, you have to specify an end
position in an existing file, or if you don't it will only follow until the
end of the current file.
That seems like an oversight - if you specify -f with no end position, it
should follow "into the future" for any new files that appear. This allows
us to track what's happening properly.
AFAICT the actual code tracks this just fine, but the option parsing
prevents this from happening as it does not allow the end pointer to be
unset. Attach patch fixes this and makes it follow "forever" if you specify
-f without an end pointer.
I'd appreciate a review of that by someone who's done more work on the xlog
stuff, but it seems trivial to me. Not sure I can argue it's a bugfix
though, since the usecase simply did not work...
--
Magnus Hagander
Me: http://www.hagander.net/
Work: http://www.redpill-linpro.com/
diff --git a/src/bin/pg_xlogdump/pg_xlogdump.c b/src/bin/pg_xlogdump/pg_xlogdump.c
index c0a6816..2f1018b 100644
--- a/src/bin/pg_xlogdump/pg_xlogdump.c
+++ b/src/bin/pg_xlogdump/pg_xlogdump.c
@@ -901,8 +901,14 @@ main(int argc, char **argv)
goto bad_argument;
}
- /* no second file specified, set end position */
- if (!(optind + 1 < argc) && XLogRecPtrIsInvalid(private.endptr))
+ /*
+ * No second file specified, so unless we are in follow mode,
+ * set the end position to the end of the same segment as
+ * the start position.
+ */
+ if (!(optind + 1 < argc) &&
+ XLogRecPtrIsInvalid(private.endptr) &&
+ !config.follow)
XLogSegNoOffsetToRecPtr(segno + 1, 0, private.endptr);
/* parse ENDSEG if passed */
@@ -933,7 +939,8 @@ main(int argc, char **argv)
}
- if (!XLByteInSeg(private.endptr, segno) &&
+ if (!XLogRecPtrIsInvalid(private.endptr) &&
+ !XLByteInSeg(private.endptr, segno) &&
private.endptr != (segno + 1) * XLogSegSize)
{
fprintf(stderr,
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
