Re: [HACKERS] [PATCH] Add pg_disable_checksums() and supporting infrastructure
От | Magnus Hagander |
---|---|
Тема | Re: [HACKERS] [PATCH] Add pg_disable_checksums() and supporting infrastructure |
Дата | |
Msg-id | CABUevEz_p1w2u1ZZR1AqNiyzT+6_D6VT-=BCodOR5vXdMODzdA@mail.gmail.com обсуждение исходный текст |
Ответ на | [HACKERS] [PATCH] Add pg_disable_checksums() and supporting infrastructure (David Christensen <david@endpoint.com>) |
Ответы |
Re: [HACKERS] [PATCH] Add pg_disable_checksums() and supportinginfrastructure
Re: [HACKERS] [PATCH] Add pg_disable_checksums() and supportinginfrastructure |
Список | pgsql-hackers |
On Thu, Feb 16, 2017 at 9:58 PM, David Christensen <david@endpoint.com> wrote:
Extracted from a larger patch, this patch provides the basic infrastructure for turning data
checksums off in a cluster. This also sets up the necessary pg_control fields to support the
necessary multiple states for handling the transitions.
We do a few things:
- Change "data_checksums" from a simple boolean to "data_checksum_state", an enum type for all of
the potentially-required states for this feature (as well as enabling).
- Add pg_control support for parsing/displaying the new setting.
- Distinguish between the possible checksum states and be specific about whether we care about
checksum read failures or write failures at all call sites, turning DataChecksumsEnabled() into two
functions: DataChecksumsEnabledReads() and DataChecksumsEnabledWrites().
- Create a superuser function pg_disable_checksums() to perform the actual disabling of this in the
cluster.
I have *not* changed the default in initdb to enable checksums, but this would be trivial.
Per the point made by somebody else (I think Simon?) on the other thread, I think it also needs WAL support. Otherwise you turn it off on the master, but it remains on on a replica which will cause failures once datablocks without checksum starts replicating.
В списке pgsql-hackers по дате отправления: