On 22 Mar 2024, at 17:00, Alban Hertroys wrote:
On Fri, 22 Mar 2024 at 15:01, Nick Renders <postg...@arcict.com>
wrote:
We now have a second machine with this issue: it is an Intel Mac mini
running macOS Sonoma (14.4) and PostgreSQL 16.2.
This one only has a single Data directory, so there are no multiple
instances running.
I don't think that having a single Data directory prevents multiple
instances from running. That's more of a matter of how often pg_ctl
was
called with the start command for that particular data directory.
I installed Postgres yesterday and restored a copy from our live
database
in the Data directory.
How did you restore that copy? Was that a file-based copy perhaps?
Your
files may have incorrect owners or permissions in that case.
The Postgres process started up without problems, but after 40
minutes it
started throwing the same errors in the log:
2024-03-21 11:49:27.410 CET [1655] FATAL: could not open
file
"global/pg_filenode.map": Operation not permitted
2024-03-21 11:49:46.955 CET [1760] FATAL: could not open
file
"global/pg_filenode.map": Operation not permitted
2024-03-21 11:50:07.398 CET [965] LOG: could not open file
"postmaster.pid": Operation not permitted; continuing anyway
It's possible that some other process put a lock on these files.
Spotlight
perhaps? Or TimeMachine?
I stopped and started the process, and it continued working again
until
around 21:20, when the issue popped up again. I wasn't doing anything
on
the machine at that time, so I have no idea what might have triggered
it.
Is there perhaps some feature that I can enable that logs which
processes
use these 2 files?
IIRC, MacOS comes shipped with the lsof command, which will tell you
which
processes have a given file open. See man lsof.
--
If you can't see the forest for the trees,
Cut the trees and you'll see there is no forest.
I have tried the lsof command, but it returns no info about the
postmaster.pid and global/pg_filenode.map files, so I take they are not
open at that moment.
Spotlight indexing has been disabled, and TimeMachine takes no snapshots
of the volume where the data resides.
Looking at the 2 machines that are having this issue (and the others
that don't), I think it is somehow related to the following setup:
- macOS Sonoma (14.4 and 14.4.1)
- data directory on an external drive
That external drive (a Promise RAID system in one case, a simple SSD in
the other) has the option "ignore ownership" on by default. I have tried
disabling that, and updating the data directory to have owner +
read/write access for the postgres user. It seemed to work at first, but
just now the issue re-appeared again.
Any other suggestions?
Thanks,
Nick Renders
