Re: [Patch] Checksums for SLRU files

Поиск
Список
Период
Сортировка
От Thomas Munro
Тема Re: [Patch] Checksums for SLRU files
Дата
Msg-id CAEepm=3z=HOr0FtZ9aJYL9rpFbXxU-u=rt==fQw4__47oyvw+w@mail.gmail.com
обсуждение исходный текст
Ответ на Re: [Patch] Checksums for SLRU files  (Alexander Korotkov <a.korotkov@postgrespro.ru>)
Ответы Re: [Patch] Checksums for SLRU files
Re: [Patch] Checksums for SLRU files
Список 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 по дате отправления:

Предыдущее
От: Thomas Munro
Дата:
Сообщение: Re: Query running for very long time (server hanged) with parallel append
Следующее
От: Robert Haas
Дата:
Сообщение: Re: [HACKERS] path toward faster partition pruning