Re: pg_waldump command line arguments

From: Andres Freund <andres(at)anarazel(dot)de>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: pg_waldump command line arguments
Date: 2017-06-16 17:58:28
Message-ID: 20170616175828.m3b3jdhkvbdrkxak@alap3.anarazel.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 2017-06-15 17:08:23 -0400, Robert Haas wrote:
> pg_waldump --help claims that you run it like this:
>
> Usage:
> pg_waldump [OPTION]... [STARTSEG [ENDSEG]]
>
> And https://www.postgresql.org/docs/10/static/pgwaldump.html agrees.
> Since square brackets indicate optional arguments, this sort of makes
> it sound like running pg_waldump with no arguments ought to work. But
> it doesn't:

Well, not really, it indicates that positional arguments are allowed,
but not required. You can get by with with -s / -e, which are sometimes
important, if you want to look at multiple timelines etc.

> A slightly broader concern is whether we need to require the start
> position at all. It seems like one could locate the WAL directory
> using the existing logic, then search for the earliest file.

"earliest file" isn't actually that trivial to determine if there's
timelines etc. But leaving that aside, it'll be frequently so much data
that'll be output, that it'd make the output pretty much useless, no? I
think if we were to add a bit more magic, it'd make more sense to parse
pg_control and start at the last flushed point nof WAL forward,
especially with -f.

> It might be a little unclear what "earliest" means when multiple
> timelines are present, but I bet we could come up with some behavior
> that would be convenient for most users. It would be quite handy to
> be able to run this without arguments (or just with -z) and have it
> process all the WAL files that you've got on hand.

With -z I agree, probably best by parsing pg_control and parsing
[checkpoint - 1, minRecoveryPoint) or such.

I'm willing to review some patches here, but I don't plan to personally
work on patches around this...

Greetings,

Andres Freund

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Andres Freund 2017-06-16 18:02:12 Re: Preliminary results for proposed new pgindent implementation
Previous Message Alexey Kondratov 2017-06-16 17:53:52 Re: GSOC'17 project introduction: Parallel COPY execution with errors handling