| From: | Thomas Munro <thomas(dot)munro(at)gmail(dot)com> |
|---|---|
| To: | Nick Renders <postgres(at)arcict(dot)com> |
| Cc: | pgsql-general(at)lists(dot)postgresql(dot)org |
| Subject: | Re: could not open file "global/pg_filenode.map": Operation not permitted |
| Date: | 2024-04-03 21:14:33 |
| Message-ID: | CA+hUKGLKbx+zjqthDp1YS=uiWB9PJ2p56BGx+iYUB3LmPN8p5Q@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-general |
On Sat, Mar 23, 2024 at 3:01 AM Nick Renders <postgres(at)arcict(dot)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.
BTW if you're running databases on mains-powered Macs, I have a patch
that you might be interested in, which so far hasn't attracted any
reviews. The short version is that I bet you can at least lose many
seconds of commits (because WAL doesn't really hit durable part of
disk), and possibly also fail to recover (pg_control hits disk before
WAL, not sure if this is really possible), if you yank the power and
you're using the default settings for wal_sync_method. I'd like to
rationalise the settings for that stuff and make it safe by default.
I don't know anything about the USB storage pathway but I'd be
surprised if it's different.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Michael Paquier | 2024-04-04 00:34:19 | Re: recovery.signal not being removed when recovery complete |
| Previous Message | Adrian Klaver | 2024-04-03 21:11:37 | Re: Moving delta data faster |