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: Robert Haas <robertmhaas@gmail.com>, Heikki Linnakangas <hlinnaka@iki.fi>, Alexander Lakhin <exclusion@gmail.com>, Tom Lane <tgl@sss.pgh.pa.us>, Laurenz Albe <laurenz.albe@cybertec.at>, rootcause000@gmail.com, pgsql-bugs@lists.postgresql.org
Date: 2025-01-08T03:48:03Z
Lists: pgsql-bugs 
On Wed, Jan 8, 2025 at 4:22 PM Michael Paquier <michael@paquier.xyz> wrote:
> It seems to me that you meant to do the following in the back
> branches:

> -       return smgrtruncate2(reln, forknum, nforks, old_nblocks, nblocks);
> +       smgrtruncate2(reln, forknum, nforks, old_nblocks, nblocks);

Right, that was accepted by my compiler and apparently almost all the
others, but is not really allowed in C (it's allowed in C++, and
useful for generic forwarding).  Duh.  Will fix.

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.