From: | Stephen Frost <sfrost(at)snowman(dot)net> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Daniel Gustafsson <daniel(at)yesql(dot)se>, pgsql-hackers(at)lists(dot)postgresql(dot)org |
Subject: | Re: Minor typo |
Date: | 2018-11-28 00:45:09 |
Message-ID: | 20181128004509.GN3415@tamriel.snowman.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Greetings,
* Tom Lane (tgl(at)sss(dot)pgh(dot)pa(dot)us) wrote:
> Daniel Gustafsson <daniel(at)yesql(dot)se> writes:
> >> On 28 Nov 2018, at 00:43, Stephen Frost <sfrost(at)snowman(dot)net> wrote:
> >> Sending it here in case anyone feels that we should do more than just
> >> correct the word..? Perhaps for non-native English speakers seeing
> >> "whose" used here is confusing?
>
> > Being a non-native English speaker I think it’s fine and, in my own bias,
> > commonly understood.
>
> I agree that "which" is just wrong here, but "whose" seems a bit malaprop
> as well, and it's not the only poor English in that sentence. Maybe
> rewrite the whole sentence to avoid the problem?
>
> * When wal_compression is enabled and a "hole" is removed from a full
> * page image, the page image is compressed using PGLZ compression.
Yeah, that seems a bit cleaner.
> (BTW, is this trying to say that we don't apply compression if the page
> contains no hole? If so, why not?)
Sure seems to be saying that, and later on..
* If BKPIMAGE_HAS_HOLE and BKPIMAGE_IS_COMPRESSED, an
* XLogRecordBlockCompressHeader struct follows.
Yet XLogCompressBackupBlock() sure looks like it'll happily compress a
page even if it doesn't have a hole. The replay logic certainly seems
to only check if BKPIMAGE_IS_COMPRESSED is set.
I'm thinking there's quite a bit of room for improvement here... I
wonder if the idea originally was "the page is 'compressed', in some
way, if it either had a hole or was actually compressed"..
Thanks!
Stephen
From | Date | Subject | |
---|---|---|---|
Next Message | Stephen Frost | 2018-11-28 00:51:03 | Re: Minor typo |
Previous Message | Justin Pryzby | 2018-11-28 00:44:02 | Re: Query with high planning time at version 11.1 compared versions 10.5 and 11.0 |