Re: [HACKERS] Setting pd_lower in GIN metapage

Поиск
Список
Период
Сортировка
От Amit Kapila
Тема Re: [HACKERS] Setting pd_lower in GIN metapage
Дата
Msg-id CAA4eK1JFK6Yru-gqVp-qkWp-2Cj2ecCfGi1SVkW6TmLA6SZ_MQ@mail.gmail.com
обсуждение исходный текст
Ответ на Re: [HACKERS] Setting pd_lower in GIN metapage  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
On Fri, Sep 8, 2017 at 1:54 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Michael Paquier <michael.paquier@gmail.com> writes:
>> On Thu, Sep 7, 2017 at 2:40 PM, Amit Langote
>> <Langote_Amit_f8@lab.ntt.co.jp> wrote:
>>> On 2017/09/07 13:09, Michael Paquier wrote:
>>>> pd_lower should remain at 0 on pre-10 servers.
>
>>> Doesn't PageInit(), which is where any page gets initialized, has always
>>> set pd_lower to SizeOfPageHeaderData?
>
>> Yes, sorry. I had a mind slippery here..
>
> Indeed, which raises the question of how did any of this code work at all?
> Up to now, these pages have been initialized with pd_lower =
> SizeOfPageHeaderData, *not* zero.  Which means that the FPI code would
> have considered the metadata to be part of a valid "hole" and not stored
> it, if we'd ever told the FPI code that the metadata page was of standard
> format.  I've just looked through the code for these three index types and
> can't find any place where they do that --- for instance, they don't pass
> REGBUF_STANDARD to XLogRegisterBuffer when writing their metapages, and
> they pass page_std = false to log_newpage when using that for metapages.
> Good thing, because they'd be completely broken otherwise.
>
> This means that the premise of this patch is wrong.  Adjusting pd_lower,
> by itself, would accomplish precisely zip for WAL compression, because
> we'd still not be telling the WAL code to compress out the hole.
>
> To get any benefit, I think we'd need to do all of the following:
>
> 1. Initialize pd_lower correctly in the metapage init functions, as here.
>
> 2. Any place we are about to write the metapage, set its pd_lower to the
> correct value, in case it's an old index that doesn't have that set
> correctly.  Fortunately this is cheap enough that we might as well just
> do it unconditionally.
>
> 3. Adjust all the xlog calls to tell them the page is of standard format.
>
> Now, one advantage we'd get from this is that we could say confidently
> that any index metapage appearing in a WAL stream generated by v11 or
> later has got the right pd_lower; therefore we could dispense with
> checking for wrong pd_lower in the mask functions (unless they're used
> in some way I don't know about, which is surely possible).
>
> BTW, while nbtree correctly initializes pd_lower, it looks to me like it
> is not exploiting that, because it seems never to pass REGBUF_STANDARD for
> the metapage anyway.
>

During the creation of the index, it uses log_newpage to log metapage
and there it uses REGBUF_STANDARD.  So, there seems to be some use of
it.

-- 
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Pavel Stehule
Дата:
Сообщение: Re: [HACKERS] pgbench more operators & functions
Следующее
От: Amit Kapila
Дата:
Сообщение: Re: [HACKERS] Setting pd_lower in GIN metapage