On 22 Mar 2024, at 17:00, Alban Hertroys wrote:
On Fri, 22 Mar 2024 at 15:01, Nick Renders <postgres@xxxxxxxxxx> 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 anywayIt'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
