Re: [Patch] Checksums for SLRU files - Mailing list pgsql-hackers

From Thomas Munro
Subject Re: [Patch] Checksums for SLRU files
Date
Msg-id CAEepm=3z=HOr0FtZ9aJYL9rpFbXxU-u=rt==fQw4__47oyvw+w@mail.gmail.com
Whole thread Raw
In response to Re: [Patch] Checksums for SLRU files  (Alexander Korotkov <a.korotkov@postgrespro.ru>)
Responses Re: [Patch] Checksums for SLRU files  (Andres Freund <andres@anarazel.de>)
Re: [Patch] Checksums for SLRU files  (Andrey Borodin <x4mmm@yandex-team.ru>)
List pgsql-hackers
On Wed, Jan 3, 2018 at 11:21 AM, Alexander Korotkov
<a.korotkov@postgrespro.ru> wrote:
> On Mon, Jan 1, 2018 at 9:19 PM, Andrey Borodin <x4mmm@yandex-team.ru> wrote:
>> > 31 дек. 2017 г., в 22:30, Ivan Kartyshov <i.kartyshov@postgrespro.ru>
>> > написал(а):
>> >
>> > Hello, I`d like to show my implementation of SLRU file protection with
>> > checksums.
>> > .....
>> > I would like to hear your thoughts over my patch.
>>
>> As far as I can see, the patch solves problem of hardware corruption in
>> SLRU.
>> This seems a valid concern.

+1

It doesn't make sense to have a checksum feature that protects
relation files, but doesn't protect these super important meta-data
files that affect our interpretation of the relation files.

> [...]
> 3. pg_upgrade isn't considered.  This patch should provide upgrading SLRUs
> to adopt changed useful size of page.  That seems to be hardest patch of
> this patch to be written.

+1

I think we'd want pg_upgrade tests showing an example of each SLRU
growing past one segment, and then being upgraded, and then being
accessed in various different pages and segment files, so that we can
see that we're able to shift the data to the right place successfully.
For example I think I'd want to see that a single aborted transaction
surrounded by many committed transactions shows up in the right place
after an upgrade.

--
Thomas Munro
http://www.enterprisedb.com


pgsql-hackers by date:

Previous
From: Thomas Munro
Date:
Subject: Re: Query running for very long time (server hanged) with parallel append
Next
From: Robert Haas
Date:
Subject: Re: [HACKERS] path toward faster partition pruning