pg.ddx.io  pgsql-bugs@postgresql.org mailing list archive  
help / color / mirror / Atom feed
From: Noah Misch <noah@leadboat.com>
To: Ronan Dunklau <ronan.dunklau@aiven.io>
Cc: Michael Paquier <michael@paquier.xyz>
Cc: pgsql-bugs <pgsql-bugs@lists.postgresql.org>
Subject: Re: FSM Corruption (was: Could not read block at end of the relation)
Date: Sat, 13 Apr 2024 10:15:28 -0700
Message-ID: <20240413171528.59.nmisch@google.com> (raw)
In-Reply-To: <20240411153843.20@rfd.leadboat.com>
References: <VtPLBUerbMM8BSDLQwIMV9Co_38iHS1TXE4V09x2ZVFhPkZMNE8LwgPSIzB8PHkVFXykGx04QNAzZVjJFAnU1w==@protonmail.internalid>
	<6055942.lOV4Wx5bFT@aivenlaptop>
	<20240406223037.c5@rfd.leadboat.com>
	<5959995.31r3eYUQgx@aivenlaptop>
	<20240411153843.20@rfd.leadboat.com>

On Thu, Apr 11, 2024 at 08:38:43AM -0700, Noah Misch wrote:
> On Thu, Apr 11, 2024 at 09:36:50AM +0200, Ronan Dunklau wrote:
> > Le dimanche 7 avril 2024, 00:30:37 CEST Noah Misch a écrit :
> > > Your v3 has the right functionality.  As further confirmation of the fix, I
> > > tried reverting the non-test parts of commit 917dc7d "Fix WAL-logging of FSM
> > > and VM truncation".  That commit's 008_fsm_truncation.pl fails with 917dc7d
> > > reverted from master, and adding this patch makes it pass again.  I ran
> > > pgindent and edited comments.  I think the attached version is ready to go.
> > 
> > Thank you Noah, the updated comments are much better. I think it should be 
> > backported at least to 16 since the chances of tripping on that behaviour are 
> > quite high here, but what about previous versions ?
> 
> It should be reachable in all branches, just needing concurrent extension lock
> waiters to reach before v16.  Hence, my plan is to back-patch it all the way.
> It applies with negligible conflicts back to v12.

While it applied, it doesn't build in v12 or v13, due to smgr_cached_nblocks
first appearing in c5315f4.  Options:

1. Back-patch the addition of smgr_cached_nblocks or equivalent.
2. Stop the back-patch of $SUBJECT at v14.
3. Incur more lseek() in v13 and v12.

Given the lack of reports before v16, (3) seems too likely to be a cure worse
than the disease.  I'm picking (2) for today.  We could do (1) tomorrow, but I
lean toward (2) until someone reports the problem on v13 or v12.  The
problem's impact is limited to DML giving ERROR when it should have succeeded,
and I expect VACUUM FULL is a workaround.  Without those mitigating factors, I
would choose (1).

Pushed that way, as 9358297.





view thread (32+ messages)  latest in thread

Message-ID: <20240413171528.59.nmisch@google.com>
Permalink:  ../20240413171528.59.nmisch@google.com/
Also on:    postgresql.org/message-id/20240413171528.59.nmisch@google.com

 · 

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: pgsql-bugs@postgresql.org
  Cc: noah@leadboat.com, ronan.dunklau@aiven.io, michael@paquier.xyz, pgsql-bugs@lists.postgresql.org
  Subject: Re: FSM Corruption (was: Could not read block at end of the relation)
  In-Reply-To: <20240413171528.59.nmisch@google.com>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox