Re: could not open file "global/pg_filenode.map": Operation not permitted
postgres@arcict.com
From: Nick Renders <postgres@arcict.com>
To: pgsql-general@lists.postgresql.org
Date: 2024-03-28T15:47:44Z
Lists: pgsql-general
On 22 Mar 2024, at 17:00, Alban Hertroys wrote: > On Fri, 22 Mar 2024 at 15:01, Nick Renders <postgres@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
Commits
Same data as JSON:
GET /api/v1/messages/:b64id/commits
the thread's linked commits as JSON, with link sources.
API reference →
-
Remove the restriction that the relmap must be 512 bytes.
- d8cd0c6c95c0 16.0 cited