From: | Michael Paquier <michael(at)paquier(dot)xyz> |
---|---|
To: | Justin Pryzby <pryzby(at)telsasoft(dot)com> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: typos |
Date: | 2022-01-24 07:01:47 |
Message-ID: | Ye5O2zRtPoVbOEhV@paquier.xyz |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Sun, Jan 23, 2022 at 09:00:01PM -0600, Justin Pryzby wrote:
> Feel free to ignore this for now and revisit in April...
I don't mind fixing that now. That means less to do later.
> @Michael: I'm not sure what this is trying to say.
> 1e9475694b0ae2cf1204d01d2ef6ad86f3c7cac8
> + First, scan the directory where the WAL segment files are written and
> + find the newest completed segment file, using as starting point the
> + beginning of the next WAL segment file. This is calculated independently
> + on the compression method used to compress each segment.
>
> I suppose it should say independently *of* the compression method, but then I
> still don't know what it means. I checked FindStreamingStart().
> It that doesn't look like it's "calculated independently" - actually, it takes
> the compression method into account and explicitly handles each compression
> method.
This means that we are able to calculate the starting LSN even if the
segments stored use different compression methods or are
uncompressed. Would you reword that differently? Or perhaps removing
the last sentence of this paragraph would be simpler in the long run?
--
Michael
From | Date | Subject | |
---|---|---|---|
Next Message | Justin Pryzby | 2022-01-24 07:07:54 | Re: typos |
Previous Message | Masahiko Sawada | 2022-01-24 06:54:35 | Re: Skipping logical replication transactions on subscriber side |