Re: smgrzeroextend clarification
От | Thomas Munro |
---|---|
Тема | Re: smgrzeroextend clarification |
Дата | |
Msg-id | CA+hUKGKv8VttnkZaqdge8c=Jed+1KqoFfW_pF6zn_55PS71cRA@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: smgrzeroextend clarification (Greg Stark <stark@mit.edu>) |
Ответы |
Re: smgrzeroextend clarification
|
Список | pgsql-hackers |
On Sat, May 13, 2023 at 6:07 AM Greg Stark <stark@mit.edu> wrote: > 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. Just a thought: should RelationCopyStorageUsingBuffer(), the new code used by CREATE DATABASE with the default strategy WAL_LOG, use the newer interface so that it creates fully allocated files instead of sparse ones?
В списке pgsql-hackers по дате отправления: