Horton

Re: Enable data checksums by default

Bruce Momjian <bruce@momjian.us>

View thread
From: Bruce Momjian <bruce@momjian.us>
To: Heikki Linnakangas <hlinnaka@iki.fi>
Cc: Peter Eisentraut <peter@eisentraut.org>, Tomas Vondra <tomas@vondra.me>, Nathan Bossart <nathandbossart@gmail.com>, Greg Sabino Mullane <htamfids@gmail.com>, Michael Paquier <michael@paquier.xyz>, Michael Banck <mbanck@gmx.net>, pgsql-hackers <pgsql-hackers@postgresql.org>
Date: 2025-05-23T21:08:59Z
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. Avoid BufferGetLSNAtomic() calls during nbtree scans.

  2. doc PG 18 relnotes: Add incompatibility note about checksums now default

  3. Fix pg_upgrade's cross-version tests when old < 18

  4. initdb: Change default to using data checksums.

  5. Allow TAP tests to force checksums off when calling init()

  6. initdb: Add new option "--no-data-checksums"

  7. Tweak docs to reduce possible impact of data checksums

On Fri, May 23, 2025 at 11:10:47AM +0300, Heikki Linnakangas wrote:
> On 24/04/2025 14:26, Peter Eisentraut wrote:
> > action for beta1 is (a).  And then for (c) perhaps monitor the feedback
> > between beta1 and beta2.
> > 
> 
> Ping: It's time to do something about this open item. (Or decide to do
> nothing I guess). We're already in beta, but at the same time, we're still
> early in the beta and now is the last chance for code changes before 18 is
> shipped.
> 
> Aside from just documenting it, I see two things we could do:
> 
> 1. Have pg_upgrade run initdb for you. It's always felt silly that you need
> to run initdb with the new version yourself, when there's really only one
> correct way to do it. pg_upgrade has all the checks to verify that you did
> it right, so why doesn't it just do it itself? I think that'd be a good
> long-term solution. Might be too late for 18, but I'm not sure. If someone
> wrote the patch we could evaluate it. To use that mode, the scripts calling
> pg_upgrade would need to be changed, though, so we'd perhaps want to do #2
> or something else in addition to this.

The pg_upgrade docs suggest why having pg_upgrade run initdb could be
limiting:

	5. Install extension shared object files

	Many extensions and custom modules, whether from contrib or another
	source, use shared object files (or DLLs), e.g., pgcrypto.so. If
	the old cluster used these, shared object files matching the new
	server binary must be installed in the new cluster, usually via
	operating system commands. Do not load the schema definitions,
	e.g., CREATE EXTENSION pgcrypto, because these will be duplicated
	from the old cluster. If extension updates are available,
	pg_upgrade will report this and create a script that can be run
	later to update them.

	6. Copy custom full-text search files

	Copy any custom full text search files (dictionary, synonym,
	thesaurus, stop words) from the old to the new cluster.

	7. Adjust authentication

	pg_upgrade will connect to the old and new servers several times,
	so you might want to set authentication to peer in pg_hba.conf
	or use a ~/.pgpass file (see Section 32.16).


I have also heard of cases where postgresql.conf must be modified for
pg_upgrade to succeed, and of course initdb installs postgresql.conf.

Should #5 be after #6?

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

  Do not let urgent matters crowd out time for investment in the future.