| From: | Greg Stark <stark(at)mit(dot)edu> |
|---|---|
| To: | Peter Eisentraut <peter(dot)eisentraut(at)enterprisedb(dot)com> |
| Cc: | Andres Freund <andres(at)anarazel(dot)de>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: smgrzeroextend clarification |
| Date: | 2023-05-12 18:06:38 |
| Message-ID: | CAM-w4HPfR+WXepWrX6gJ7EZ9zY-avGGABmOL-D97fR_gHCZEgA@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Thu, 11 May 2023 at 05:37, Peter Eisentraut
<peter(dot)eisentraut(at)enterprisedb(dot)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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Thomas Munro | 2023-05-12 18:36:23 | Re: smgrzeroextend clarification |
| Previous Message | Ryan Booz | 2023-05-12 17:37:34 | Re: Overhauling "Routine Vacuuming" docs, particularly its handling of freezing |