Horton

Re: Changing the state of data checksums in a running cluster

Bruce Momjian <bruce@momjian.us>

View thread
From: Bruce Momjian <bruce@momjian.us>
To: Tomas Vondra <tomas.vondra@enterprisedb.com>
Cc: Daniel Gustafsson <daniel@yesql.se>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2024-07-06T02:23:35Z
Lists: pgsql-hackers

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. Use correct datatype for PID

  2. Improve comments in online checksums code

  3. Fix checksum state transition during promotion

  4. Fix regex searching for page verification failures in tests

  5. Apply data-checksum worker throttling parameters

  6. Skip WAL for unlogged main fork during online checksum enable

  7. Revert "Get rid of WALBufMappingLock"

  8. Get rid of WALBufMappingLock

  9. Improve grammar of options for command arrays in TAP tests

On Wed, Jul  3, 2024 at 01:20:10PM +0200, Tomas Vondra wrote:
> > * Restartability - the initial version of the patch did not support stateful
> > restarts, a shutdown performed (or crash) before checksums were enabled would
> > result in a need to start over from the beginning.  This was deemed the safe
> > orchestration method.  The lack of this feature was seen as serious drawback,
> > so it was added.  Subsequent review instead found the patch to be too
> > complicated with a too large featureset.  I thihk there is merit to both of
> > these arguments: being able to restart is a great feature; and being able to
> > reason about the correctness of a smaller patch is also great.  As of this
> > submission I have removed the ability to restart to keep the scope of the patch
> > small (which is where the previous version was, which received no review after
> > the removal).  The way I prefer to frame this is to first add scaffolding and
> > infrastructure (this patch) and leave refinements and add-on features
> > (restartability, but also others like parallel workers, optimizing rare cases,
> > etc) for follow-up patches.
> > 
> 
> I 100% support this approach.

Yes, I was very disappointed when restartability sunk the patch, and I
saw this as another case where saying "yes" to every feature improvement
can lead to failure.

-- 
  Bruce Momjian  <bruce@momjian.us>        https://momjian.us
  EDB                                      https://enterprisedb.com

  Only you can decide what is important to you.