Content-Type: text/plain;
	charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3774.400.31\))
Subject: Re: PostgreSQL & latest Mac OS Sonoma, a possible bug / configuration
 issue
From: Arnd Baranowski <baranowski@oculeus.com>
In-Reply-To: <319901.1707185894@sss.pgh.pa.us>
Date: Tue, 6 Feb 2024 09:07:31 +0100
Cc: pgsql-bugs@postgresql.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <CE2891D3-CE47-4570-BA26-B0F7A7277B2A@oculeus.com>
References: <C87F1481-6A03-45E3-BE60-C55F568220C0@oculeus.com>
 <269596.1707165898@sss.pgh.pa.us>
 <E51BA147-F341-485D-8384-FCF6CA3CF7E4@oculeus.com>
 <319901.1707185894@sss.pgh.pa.us>
To: Tom Lane <tgl@sss.pgh.pa.us>
UI-OutboundReport: notjunk:1;M01:P0:vM6M6eZi64g=;JF60r7rMlP31D6my5uC/D+W1Oga
 y4ynpYuPxDhjlhFEXFGjuUpN9vYn9uujLZuDyyQCzT6yi6ZK4h6YqRASn6P6yyo2ezwfcJlCR
 RnhGP63NTsJL8bzcjMLCm6iYsfDsMZkaWH89x1My5s3urm8BOUIV73dDRW+IUdi5JKsjlDwdb
 7R7NofrgkycQfFqOUS0Soea1vCYQtqooe6dklgN2gIzc6PuleZjhlhW8LSZcD+tT7D6W2+20j
 0nLT7VB/WsqFepcYYXHFWpMhr0Tapb19nx9hCWxlPgM1v93wdQXoi2A5R284wSfWTI8ytclr6
 psG9SLzaklB/dxuZ9BWeN/5Kil8rh7WEMmcBw8madFSGWIAs6TgQi0X42ZtjoyeZOTcR9XEHQ
 ep+PHx7yqWqY1p4XKPRcTM2Li3CKl8E+ip3FfuBxxoe8nFq923+LuFidJYECVjonQmEIDS80w
 MO5Uvn+Ac4mp6rUJrNyysk8BcBXKOONLx/z+GyAMoRzJpeSkQE3QkhdTQtAcumvyNs3sq7X48
 Lw+WJWkR0eU13CPJEhHFrS2zDlRU4jkXj8ijJliT43YqXiC18N6rUQL39H8wnQ/PcD7OV/Zqf
 Ylsy2SDZO6NelICsmgrgMhpfNqJNGPtSbd0K1kMBJP55lLAJ4pDdvNb4R6TxlG2pm2omXTTc/
 QNHUCD6FAF252qjkmjq/JdDmACrCOh3+2daIUfhmbKv3EvZKEgpG07+dvCNYJdpAwV3QjZyqz
 7pLBFp4cRRwNjZ3rHv7Xfwi6B1MJB3mAinBVtmL/KBZVf8qalaErqk=
Archived-At: 
 <https://www.postgresql.org/message-id/CE2891D3-CE47-4570-BA26-B0F7A7277B2A%40oculeus.com>
Precedence: bulk

Hi Tom,

Thanks for the feedback and insights. I will follow your advice, observe =
and report if I find something which could explain this behavior

Regard

Arnd

> Am 06.02.2024 um 03:18 schrieb Tom Lane <tgl@sss.pgh.pa.us>:
>=20
> Arnd Baranowski <baranowski@oculeus.com> writes:
>> Correction fsync is =E2=80=9EOn" and the wal_sync_method is set to =
=E2=80=9Eopen_datasync=E2=80=9C
>=20
> That's what they should be.
>=20
> 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
>=20
> 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
>=20
> 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.)
>=20
> 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.
>=20
> 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 =3D on for awhile, and see if there are
> log entries claiming successful checkpoint completion.
>=20
> 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.
>=20
> 			regards, tom lane