Re: Enable data checksums by default
От | Greg Sabino Mullane |
---|---|
Тема | Re: Enable data checksums by default |
Дата | |
Msg-id | CAKAnmmKOiLgF2mWZobbfUH5VteJfOS+QtAMTuhBxHB5i3mcRqA@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Enable data checksums by default (Michael Banck <mbanck@gmx.net>) |
Ответы |
Re: Enable data checksums by default
|
Список | pgsql-hackers |
On Wed, Aug 7, 2024 at 4:43 AM Michael Banck <mbanck@gmx.net> wrote:
I think the last time we dicussed this the consensus was that
computational overhead of computing the checksums is pretty small for
most systems (so the above change seems warranted regardless of whether
we switch the default), but turning on wal_compression also turns on
wal_log_hints, which can increase WAL by quite a lot. Maybe this is
covered elsewhere in the documentation (I just looked at the patch), but
if not, it probably should be added here as a word of caution.
Yeah, that seems something beyond this patch? Certainly we should mention wal_compression in the release notes if the default changes. I mean, I feel wal_log_hints should probably default to on as well, but I've honestly never really given it much thought because my fingers are trained to type "initdb -k". I've been using data checksums for roughly a decade now. I think the only time I've NOT used checksums was when I was doing checksum overhead measurements, or hacking on the pg_checksums program.
I think we usually do not mention when a feature was added/changed, do
we? So I'd just write "(default: enabled)" or whatever is the style of
the surrounding options.
+1
> + {"no-data-checksums", no_argument, NULL, 20},
Does it make sense to add -K (capital k) as a short-cut for this? I
think this is how we distinguish on/off for pg_dump (-t/-T etc.) but
maybe that is not wider project policy.
I'd rather not. Better to keep it explicit rather than some other weird letter that has no mnemonic value.
Cheers,
Greg
В списке pgsql-hackers по дате отправления: