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 1qoAsj-000OXE-1L for pgsql-bugs@arkaria.postgresql.org; Wed, 04 Oct 2023 23:02: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 1qoAsg-006K5X-TW for pgsql-bugs@arkaria.postgresql.org; Wed, 04 Oct 2023 23:02:15 +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 1qoAsg-006K59-L7 for pgsql-bugs@lists.postgresql.org; Wed, 04 Oct 2023 23:02:15 +0000 Received: from sss.pgh.pa.us ([68.162.161.243]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1qoAse-0004PY-K9 for pgsql-bugs@lists.postgresql.org; Wed, 04 Oct 2023 23:02:15 +0000 Received: from sss1.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.pgh.pa.us (8.15.2/8.15.2) with ESMTP id 394N29JN2648149; Wed, 4 Oct 2023 19:02:09 -0400 From: Tom Lane To: Thomas Munro cc: Michael Paquier , Laurenz Albe , rootcause000@gmail.com, pgsql-bugs@lists.postgresql.org Subject: Re: BUG #18146: Rows reappearing in Tables after Auto-Vacuum Failure in PostgreSQL on Windows In-reply-to: References: <18146-04e908c662113ad5@postgresql.org> <9fc4118d2a8f2290d8598a9c4d451c4c90b17cee.camel@cybertec.at> <2583426.1696429441@sss.pgh.pa.us> Comments: In-reply-to Thomas Munro message dated "Thu, 05 Oct 2023 10:12:27 +1300" MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-ID: <2648147.1696460529.1@sss.pgh.pa.us> Content-Transfer-Encoding: 8bit Date: Wed, 04 Oct 2023 19:02:09 -0400 Message-ID: <2648148.1696460529@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk Thomas Munro writes: > On Thu, Oct 5, 2023 at 3:26 AM Tom Lane wrote: >> I'm too lazy to check the commit log right now, but I think >> we did implement a fix for that (ie, flush dirty pages even >> if we anticipate them going away due to truncation). > This thread seems to be saying otherwise: > https://www.postgresql.org/message-id/flat/2348.1544474335%40sss.pgh.pa.us Hmph. OK, I was remembering the discussion not the (lack of) end result. > But as for what we should do about it, PANIC (as suggested by several > people) seems better than corruption, if we're not going to write some > kind of resilience? Maybe that's an acceptable answer now ... it's not great, but nobody is in love with any of the other options either. And it would definitely get DBAs' attention about this misbehavior of their file systems. regards, tom lane