| From: | Michael Paquier <michael(at)paquier(dot)xyz> |
|---|---|
| To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
| Cc: | Thomas Munro <thomas(dot)munro(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 02:53:43 |
| Message-ID: | Z2TcN-ypscC4Jomj@paquier.xyz |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-bugs |
On Thu, Dec 19, 2024 at 10:44:05AM -0500, Robert Haas wrote:
> I think mostly my thought was that if we could remove smgrtruncate()
> entirely in favor of smgrtruncatefrom(), or just keep it called
> smgrtruncate() but add a mandatory additional argument, that would be
> less error-prone than having two versions between which future hackers
> must pick.
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.
--
Michael
| From | Date | Subject | |
|---|---|---|---|
| Next Message | PG Bug reporting form | 2024-12-20 06:09:44 | BUG #18748: Old name version |
| Previous Message | Robert Haas | 2024-12-19 15:44:05 | Re: BUG #18146: Rows reappearing in Tables after Auto-Vacuum Failure in PostgreSQL on Windows |