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

From: Thomas Munro <thomas(dot)munro(at)gmail(dot)com>
To: Michael Paquier <michael(at)paquier(dot)xyz>
Cc: Heikki Linnakangas <hlinnaka(at)iki(dot)fi>, Alexander Lakhin <exclusion(at)gmail(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at>, rootcause000(at)gmail(dot)com, pgsql-bugs(at)lists(dot)postgresql(dot)org
Subject: Re: BUG #18146: Rows reappearing in Tables after Auto-Vacuum Failure in PostgreSQL on Windows
Date: 2024-09-11 03:20:04
Message-ID: CA+hUKGLi3Wjy2ZsROrojdgsy3e8XDEQVesHicFFgEOFw0aMXdQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

On Tue, Sep 10, 2024 at 12:43 PM Thomas Munro <thomas(dot)munro(at)gmail(dot)com> wrote:
> 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]);

Scratch that concern, smgrsw is static in smgr.c for now (h/t to
Andres for pointing that out in an off-list chat when I described
this...). I must have confused myself with proposals I've read to
make it so an extension *could* mess with this stuff, but it's not
done yet.

Also if this goes somewhere I should note in the commit message that
the analysis of the WaitIO issue was from Alexander L in bug #18426.

In response to

Browse pgsql-bugs by date

  From Date Subject
Next Message PG Bug reporting form 2024-09-11 06:42:48 BUG #18609: Repeated installcheck failure in test_pg_dump due to existing role
Previous Message Tomas Vondra 2024-09-10 19:47:16 Re: BUG #18598: AddressSanitizer detects use after free inside json_unique_hash_match()