pg.ddx.io  pgsql-bugs@postgresql.org mailing list archive  
help / color / mirror / Atom feed
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Arnd Baranowski <baranowski@oculeus.com>
Cc: pgsql-bugs@postgresql.org
Subject: Re: PostgreSQL & latest Mac OS Sonoma, a possible bug / configuration issue
Date: Mon, 05 Feb 2024 21:18:14 -0500
Message-ID: <319901.1707185894@sss.pgh.pa.us> (raw)
In-Reply-To: <E51BA147-F341-485D-8384-FCF6CA3CF7E4@oculeus.com>
References: <C87F1481-6A03-45E3-BE60-C55F568220C0@oculeus.com>
	<269596.1707165898@sss.pgh.pa.us>
	<E51BA147-F341-485D-8384-FCF6CA3CF7E4@oculeus.com>

Arnd Baranowski <baranowski@oculeus.com> writes:
> Correction fsync is „On" and the wal_sync_method is set to „open_datasync“

That's what they should be.

I tried to reproduce this by selecting "Restart..." immediately after
creating/populating a table on my own MacBook running Sonoma 14.3.
After the reboot, the table was there with the expected contents.
Now, this test doesn't actually prove a heck of a lot about PG's
crash recovery, because I see in the postmaster log

2024-02-05 21:00:30.322 EST [1148] LOG:  database system was shut down at 2024-02-05 20:58:46 EST
2024-02-05 21:00:30.327 EST [1144] LOG:  database system is ready to accept connections

which indicates that Postgres had time to perform a clean shutdown
before the system rebooted.  (That is the expected scenario for an
OS reboot, assuming that the kernel delivers us SIGTERM as it's
required to do by POSIX and then gives us enough time to nail the
windows shut, which it's not required to do.)

The facts as you've presented them indicate that (1) checkpoints
weren't working, (2) we didn't get SIGTERM at system shutdown, *and*
(3) WAL wasn't written out to disk as it's supposed to be.  It's
a bit hard to credit that so many things are broken and nobody has
noticed.  I'm inclined to wonder if something is wrong with your
disk drive.

It would be interesting to know what appears in the first few lines
of your postmaster log after a data-losing restart.  Also, try
running with log_checkpoints = on for awhile, and see if there are
log entries claiming successful checkpoint completion.

A different line of thought is that maybe the corruption is happening
because you have two postmasters started in the same data directory.
We have interlocks that are supposed to defend against that, but it'd
be a lot easier to credit that those aren't working than that all the
rest of this stuff broke.

			regards, tom lane





view thread (7+ messages)  latest in thread

Message-ID: <319901.1707185894@sss.pgh.pa.us>
Permalink:  ../319901.1707185894@sss.pgh.pa.us/
Also on:    postgresql.org/message-id/319901.1707185894@sss.pgh.pa.us

 · 

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: pgsql-bugs@postgresql.org
  Cc: tgl@sss.pgh.pa.us, baranowski@oculeus.com
  Subject: Re: PostgreSQL & latest Mac OS Sonoma, a possible bug / configuration issue
  In-Reply-To: <319901.1707185894@sss.pgh.pa.us>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox