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 1uf42R-001flP-Fe for pgsql-general@arkaria.postgresql.org; Thu, 24 Jul 2025 22:03:44 +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 1uf42Q-00BkhV-IU for pgsql-general@arkaria.postgresql.org; Thu, 24 Jul 2025 22:03:42 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1uf42Q-00BkgQ-80 for pgsql-general@lists.postgresql.org; Thu, 24 Jul 2025 22:03:42 +0000 Received: from luna.openvistas.net ([207.158.15.156] helo=openvistas.net) by magus.postgresql.org with esmtp (Exim 4.96) (envelope-from ) id 1uf42L-000fpo-2A for pgsql-general@lists.postgresql.org; Thu, 24 Jul 2025 22:03:40 +0000 Received: (qmail 73440 invoked from network); 24 Jul 2025 22:03:35 -0000 Received: from unknown (HELO ?10.0.26.39?) (jross@154.27.111.134) de/crypted with TLSv1.3: AEAD-AES128-GCM-SHA256 [128/128] DN=none by mail.openvistas.net with ESMTPSA; 24 Jul 2025 22:03:35 -0000 Message-ID: <60027457-1b85-4a69-a67e-ee87f7cabd61@openvistas.net> Date: Thu, 24 Jul 2025 16:03:34 -0600 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: PostgreSQL on S3-backed Block Storage with Near-Local Performance To: pgsql-general@lists.postgresql.org References: <8188513c-e089-4273-b2be-16dd0a5a0a80@app.fastmail.com> <5c512367-0f67-4bcc-9897-1acf9c0f8bd3@app.fastmail.com> Content-Language: en-US From: Jeff Ross In-Reply-To: <5c512367-0f67-4bcc-9897-1acf9c0f8bd3@app.fastmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On 7/24/25 13:50, Pierre Barre wrote: > It’s not “safe” or “unsafe”, there’s mountains of valid workloads which don’t require synchronous_commit. Synchronous_commit don’t make your system automatically safe either, and if that’s a requirement, there’s many workarounds, as you suggested, it certainly doesn’t make the setup useless. > > Best, > Pierre > > On Thu, Jul 24, 2025, at 21:44, Nico Williams wrote: >> On Fri, Jul 18, 2025 at 12:57:39PM +0200, Pierre Barre wrote: >>> - Postgres configured accordingly memory-wise as well as with >>> synchronous_commit = off, wal_init_zero = off and wal_recycle = off. >> Bingo. That's why it's fast (synchronous_commit = off). It's also why >> it's not safe _unless_ you have a local, fast, persistent ZIL device >> (which I assume you don't). >> >> Nico >> -- This then begs the obvious question of how fast is this with synchronous_commit = on?