Re: pg_rewind docs correction - Mailing list pgsql-hackers

From James Coleman
Subject Re: pg_rewind docs correction
Date
Msg-id CAAaqYe8xSvc6NaccSrx=-VpSS3n4NHrweDFNUmbL1EbONhqXiA@mail.gmail.com
Whole thread Raw
In response to Re: pg_rewind docs correction  (Michael Paquier <michael@paquier.xyz>)
Responses Re: pg_rewind docs correction  (James Coleman <jtc331@gmail.com>)
Re: pg_rewind docs correction  (Michael Paquier <michael@paquier.xyz>)
List pgsql-hackers


On Tue, Sep 17, 2019 at 9:41 PM Michael Paquier <michael@paquier.xyz> wrote:
On Tue, Sep 17, 2019 at 08:38:18AM -0400, James Coleman wrote:
> I don't agree that that's a valid equivalency. I myself spent a lot of
> time trying to understand how this could possibly be true a while
> back, and even looked at source code to be certain. I've asked other
> people and found the same confusion.
>
> As I read it the 2nd second sentence doesn't actually tell you the
> differences; it makes a quick attempt at summarizing *how* the first
> sentence is true, but if the first sentence isn't accurate, then it's
> hard to read the 2nd one as helping.

Well, then it comes back to the part where I am used to the existing
docs :)

> If you'd prefer something less detailed at this point at that point in
> the docs, then something along the lines of "results in a data
> directory state which can then be safely replayed from the source" or
> some such.

Actually this is a good suggestion, and could replace the first
sentence of this paragraph.

> The docs shouldn't be correct just for someone how already understands
> the intricacies. And the end user shouldn't have to read the "how it
> works" (which incidentally is kinda hidden at the bottom underneath
> the CLI args -- perhaps we could move that?) to extrapolate things in
> the primary documentation.

Perhaps.  This doc page is not that long either.

I'd set this aside for quite a while, but I was looking at it again this afternoon, and I've come to see your concern about the opening paragraphs remaining relatively simple. To that end I believe I've come up with a patch that's a good compromise: retaining that simplicity and being more clear and accurate at the same time.

In the first paragraph I've updated it to refer to both "successful rewind and subsequent WAL replay" and the result I describe as being equivalent to the result of a base backup, since that's more technically correct anyway (the current text could be read as implying a full out copy of the data directory, but that's not really true just as it isn't with pg_basebackup).

I've added the information about how the backup label control file is written, and updated the How It Works steps to refer to that separately from restart.

Additionally the How It Works is updated to include WAL segments and new relation files in the list of files copied wholesale, since that was previously stated but somewhat contradicted there.

I realized I didn't previously add this to the CF; since it's not a new patch I've added it to the current CF, but if this is incorrect please let me know.

Thanks,
James

Attachment

pgsql-hackers by date:

Previous
From: Thomas Munro
Date:
Subject: Re: [HACKERS] WIP Patch: Pgbench Serialization and deadlock errors
Next
From: James Coleman
Date:
Subject: Re: pg_rewind docs correction