| From: | Thomas Munro <thomas(dot)munro(at)gmail(dot)com> |
|---|---|
| To: | Michael Paquier <michael(at)paquier(dot)xyz> |
| Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, Heikki Linnakangas <hlinnaka(at)iki(dot)fi>, Alexander Lakhin <exclusion(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-12-20 23:15:56 |
| Message-ID: | CA+hUKGJ4jqhJVTnwiMFbmVonSMn+E9MW3YDZ+JEz9ov_h19RNA@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-bugs |
On Sat, Dec 21, 2024 at 11:18 AM Thomas Munro <thomas(dot)munro(at)gmail(dot)com> wrote:
> On Fri, Dec 20, 2024 at 3:53 PM Michael Paquier <michael(at)paquier(dot)xyz> wrote:
> > Hmm. Indeed. As a HEAD change, keeping only a smgrtruncate() is
> > tempting as it creates a parallel with md.c. I am not completely sure
> > how to make all that leaner with the smgrnblocks() calls that save the
> > old number of blocks for each fork. But perhaps Thomas has a fancy
> > idea if it comes down to that, and it could always be done later.
>
> I did that, but also back-patched it like that. I realise now that
> that was an ABI mistake, and I plan to change it back to the v5
> arrangement (smgrtruncate() unchanged, smgrtruncatefrom() with the new
> argument) in the back-branches only, just in case someone is using raw
> smgrtruncate() in compiled code in the wild. Will post a patch soon.
Here. Better/tidier ideas welcome.
| Attachment | Content-Type | Size |
|---|---|---|
| 0001-Restore-smgrtruncate-prototype-in-back-branches.patch | application/x-patch | 4.8 KB |
| From | Date | Subject | |
|---|---|---|---|
| Previous Message | Thomas Munro | 2024-12-20 22:18:23 | Re: BUG #18146: Rows reappearing in Tables after Auto-Vacuum Failure in PostgreSQL on Windows |