Horton
Menu

Re: BUG #18146: Rows reappearing in Tables after Auto-Vacuum Failure in PostgreSQL on Windows

Thomas Munro <thomas.munro@gmail.com>

View thread
From: Thomas Munro <thomas.munro@gmail.com>
To: Michael Paquier <michael@paquier.xyz>
Cc: Heikki Linnakangas <hlinnaka@iki.fi>, Alexander Lakhin <exclusion@gmail.com>, Robert Haas <robertmhaas@gmail.com>, Tom Lane <tgl@sss.pgh.pa.us>, Laurenz Albe <laurenz.albe@cybertec.at>, rootcause000@gmail.com, pgsql-bugs@lists.postgresql.org
Date: 2024-09-10T00:43:16Z
Lists: pgsql-bugs

Attachments

On Mon, Sep 9, 2024 at 8:57 PM Thomas Munro <thomas.munro@gmail.com> wrote:
> On Mon, Sep 9, 2024 at 7:21 PM Michael Paquier <michael@paquier.xyz> wrote:
> > The trick to use _mdfd_segpath() through smgrpreparetruncate() smells
> > too much of magic to me.  I don't have an idea that does not involve
> > tweaking the interface of smgr.c or some of its structures on top of
> > my mind, though, which is to save the path before the critical section
> > and pass it through (like a memory area that can be used by
> > md.c)..  Or do a MemoryContextAllowInCriticalSection, even if it is
> > not its original purpose.
...
> Another option would be to introduce mdtruncate2(old_nblocks,
> new_nblocks), so that it doesn't have to call smgrnblocks() itself,
> and you can obtain old_nblocks outside the CS...

Here is an experiment to try that out.  The requirement to call
smgrnblock() beforehand is still slightly magical, but written in
black and white.  I guess it could use an assertion cross-check on the
number of opened segments...

It is possible that an extension that messes with smgrsw[] would not
like this in a minor release:

-               smgrsw[reln->smgr_which].smgr_truncate(reln,
forknum[i], nblocks[i]);
+               smgrsw[reln->smgr_which].smgr_truncate(reln, forknum[i],
+
                    old_nblocks[i], nblocks[i]);

I don't actually know of such an extension myself.  I suppose we could
add a new member at the end called smgr_truncatefrom, and have
smgrtruncatefrom() call that if it is non-NULL (md's case), and the
existing smgr_truncate function pointer if it doesn't (ie, some
hypothetical external monkey-patching smgr replacement).  Hypothetical
forks of PostgreSQL might be more likely to have used this
interception point, but wouldn't have quite the same ABI problem
(they'd adjust their function when rebasing on a minor release, but
they might also prefer if the old function prototype still worked, or
maybe they'd have some version of this bug themselves and want to be
able to fix it...).

Hmm.

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. Fix C error reported by Oracle compiler.

  2. Restore smgrtruncate() prototype in back-branches.

  3. Fix corruption when relation truncation fails.

  4. RelationTruncate() must set DELAY_CHKPT_START.

  5. WAL-log inplace update before revealing it to other sessions.

  6. Fix bugs in MultiXact truncation

  7. Fix possible recovery trouble if TRUNCATE overlaps a checkpoint.