Обсуждение: typos

Most of this is new in v15 or doesn't affect user-facing docs so doesn't need
to be backpatched.

Feel free to ignore this for now and revisit in April...

@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.

Is there any reason the user-facing docs need to say anything about this at
all?

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

On Mon, Jan 24, 2022 at 04:01:47PM +0900, Michael Paquier wrote:
> 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.

Thanks.

> > @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?

different from what?  From each other ?

Maybe I would have written:
| This is calculated separately for each segment, which may each use
| different compression methods.

But probably I would just remove it.

-- 
Justin

On Mon, Jan 24, 2022 at 01:07:54AM -0600, Justin Pryzby wrote:
> different from what?  From each other ?

Each segment could be either uncompressed, compressed with LZ4, or
compressed with GZIP, so could be different from each other.

> Maybe I would have written:
> | This is calculated separately for each segment, which may each use
> | different compression methods.
>
> But probably I would just remove it.

I'm thinking about just removing that at the end.
--
Michael

On Mon, Jan 24, 2022 at 04:55:31PM +0900, Michael Paquier wrote:
> I'm thinking about just removing that at the end.

And done this way, keeping the whole simpler.  I have applied most of
the things you suggested, with a backpatch down to 10 for the relevant
user-visible parts in the docs.  Thanks!
--
Michael