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.
