Re: smgrzeroextend clarification - Mailing list pgsql-hackers

From Greg Stark
Subject Re: smgrzeroextend clarification
Date
Msg-id CAM-w4HPfR+WXepWrX6gJ7EZ9zY-avGGABmOL-D97fR_gHCZEgA@mail.gmail.com
Whole thread Raw
In response to Re: smgrzeroextend clarification  (Peter Eisentraut <peter.eisentraut@enterprisedb.com>)
Responses Re: smgrzeroextend clarification
List pgsql-hackers
On Thu, 11 May 2023 at 05:37, Peter Eisentraut
<peter.eisentraut@enterprisedb.com> wrote:
>
> Maybe it was never meant that way and only works accidentally?  Maybe
> hash indexes are broken?

It's explicitly documented to be this way. And I think it has to work
this way for recovery to work.

I think the reason you and Bharath and Andres are talking past each
other is that they're thinking about how the implementation works and
you're talking about the API definition.

If you read the API definition and treat the functions as a black box
I think you're right -- those two definitions sound pretty much
equivalent to me. They both extend the file, possibly multiple blocks,
and zero fill. The only difference is that smgrextend() additionally
allows you to provide data.

-- 
greg



pgsql-hackers by date:

Previous
From: Ryan Booz
Date:
Subject: Re: Overhauling "Routine Vacuuming" docs, particularly its handling of freezing
Next
From: Thomas Munro
Date:
Subject: Re: smgrzeroextend clarification