Re: BUG #18146: Rows reappearing in Tables after Auto-Vacuum Failure in PostgreSQL on Windows
От | Thomas Munro |
---|---|
Тема | Re: BUG #18146: Rows reappearing in Tables after Auto-Vacuum Failure in PostgreSQL on Windows |
Дата | |
Msg-id | CA+hUKG+Thae6x6+jmQiuALQBT2Ae1ChjMh1=kMvJ8y_SBJZrvA@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: BUG #18146: Rows reappearing in Tables after Auto-Vacuum Failure in PostgreSQL on Windows (Heikki Linnakangas <hlinnaka@iki.fi>) |
Список | pgsql-bugs |
On Fri, Dec 20, 2024 at 3:53 PM Michael Paquier <michael@paquier.xyz> wrote: > 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. Yeah. > 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.
В списке pgsql-bugs по дате отправления: