Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1rs7wy-004zLO-UB for pgsql-general@arkaria.postgresql.org; Wed, 03 Apr 2024 21:15:17 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.94.2) (envelope-from ) id 1rs7wy-008q1y-0M for pgsql-general@arkaria.postgresql.org; Wed, 03 Apr 2024 21:15:16 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1rs7wx-008q1q-Lt for pgsql-general@lists.postgresql.org; Wed, 03 Apr 2024 21:15:15 +0000 Received: from mail-lf1-x12a.google.com ([2a00:1450:4864:20::12a]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1rs7wv-000Q7v-1v for pgsql-general@lists.postgresql.org; Wed, 03 Apr 2024 21:15:14 +0000 Received: by mail-lf1-x12a.google.com with SMTP id 2adb3069b0e04-516c87a511bso166493e87.3 for ; Wed, 03 Apr 2024 14:15:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1712178911; x=1712783711; darn=lists.postgresql.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=fDf8tw1UlUtSE4+K6u9pCVALUu4hlth1EZdKDaskKFY=; b=hD/7AY6mVbynEbd3pyp03WUrk+FNmICE+ipU98ZNnz5Z6TTXzU2nEcf1Sdm+gnSxqb kJsOYIEzV6gMY7Qo7m+Kpl+2o0mnAHm8bOKnqivBLxToaqiHgWRsyjWp7TxoHxXzYiEP BMIBeUp0pMBk7eM0GlpAVCTFWx+XOUR6isAc0meYsm0iw7hduNSFGTLTWIj21Q+llEW6 GC2wa6vxoMjZSMyfMYxltpHWyac8GLCcSd55xmt4GU4CqDdeKaM/P2/9GD4y2hm3oTVW T1tPLNxIN6Zi5wrdvZPl4GtdNDpqJTcnJ36HHYDXREozj/DXY9sHi4fT6bNQYbl1ePCI vb0g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1712178911; x=1712783711; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=fDf8tw1UlUtSE4+K6u9pCVALUu4hlth1EZdKDaskKFY=; b=DxjlKQKlL4ywawmbV1+ocYfxemFYoZA6TrpnPg07iIgqnadV/7VdAtWzxbKmcdZ4vf XFo3VkWAGKbQMrvUVbbmnBWprfWs3vxgvYaolRGxMGJLNMaAZgVTj/No0nWh0ANUfoeh 4u+W7CuzFkW2yf2fevjhc7V0S0sJ0XQbAatN0D0SG9zdGluCelrVb7Ys3NJZGYzSPxrJ 9AS4PlPIsM9+Hnmk5dXWMHcN/yofUnRmpTNU2l0q7OwvvhiLqPTLExn9gAvN3znjKDAN AB9HflyLLMHn/0g25WBER+R75Yy84Z++/NLo/EridXXFl33lYbGhXDRPEFYwvg5hxC32 Is4w== X-Gm-Message-State: AOJu0YwoFbPU2uGgvhHqzkUpwoARYwQwIIhPqX8SE6c7yzFvtnoL534Y oaMDmZgKXYXiZn3WxE9ds1EOBEkvcKx15EbhqMX0v5gD83suc17DYLGynnHWj0Mh3NGs77v9NHG 0V5UxwgKjyL/0VpwHpYKh6DY7C1moj3rhqjBJ/ExU X-Google-Smtp-Source: AGHT+IGVQ6XTTq844QugYp7Er8enrpTa5OmCCTBbWp3zc817gFG93RWDpqi0Nn9g4K3hGF5xHLhSkR+z+T8RF+h0vbc= X-Received: by 2002:ac2:446d:0:b0:515:d30d:9abf with SMTP id y13-20020ac2446d000000b00515d30d9abfmr463294lfl.7.1712178910944; Wed, 03 Apr 2024 14:15:10 -0700 (PDT) MIME-Version: 1.0 References: <4D67E594-098F-4234-87D8-68F827AF2531@arcict.com> <2E2F11F8-718A-4E6A-81E0-4F5CC1F1273A@arcict.com> <19556056-40E7-4FA3-A2A1-0A345AEBFD9E@arcict.com> <76FAACAC-F64A-43DA-BDBF-340A40C47045@arcict.com> In-Reply-To: <76FAACAC-F64A-43DA-BDBF-340A40C47045@arcict.com> From: Thomas Munro Date: Thu, 4 Apr 2024 10:14:33 +1300 Message-ID: Subject: Re: could not open file "global/pg_filenode.map": Operation not permitted To: Nick Renders Cc: pgsql-general@lists.postgresql.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On Sat, Mar 23, 2024 at 3:01=E2=80=AFAM Nick Renders = wrote: > We now have a second machine with this issue: it is an Intel Mac mini run= ning macOS Sonoma (14.4) and PostgreSQL 16.2. > This one only has a single Data directory, so there are no multiple insta= nces 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. https://www.postgresql.org/message-id/flat/CA%2BhUKG%2BF0EL4Up6yVYbbcWse4xK= aqW4wc2xpw67Pq9FjmByWVg%40mail.gmail.com