Re: pageinspect: Hash index support

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Ashutosh Sharma <ashu(dot)coek88(at)gmail(dot)com>
Cc: Jesper Pedersen <jesper(dot)pedersen(at)redhat(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Mithun Cy <mithun(dot)cy(at)enterprisedb(dot)com>, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>, Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>, Michael Paquier <michael(dot)paquier(at)gmail(dot)com>, Jeff Janes <jeff(dot)janes(at)gmail(dot)com>, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: pageinspect: Hash index support
Date: 2017-02-07 13:37:56
Message-ID: CA+TgmoY-LbNudAw=n-eUNyNCyFmzTwxDepT1SQt_ka6quFNZkw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Sat, Feb 4, 2017 at 7:06 AM, Ashutosh Sharma <ashu(dot)coek88(at)gmail(dot)com> wrote:
>> As far as I can tell, the hash_bitmap_info() function is doing
>> something completely ridiculous. One would expect that the purpose of
>> this function was to tell you about the status of pages in the bitmap.
>> The documentation claims that this is what the function does: it
>> claims that this function "shows the status of a bit in the bitmap
>> page for a particular overflow page". So you would think that what
>> the function would do is:
>>
>> 1. Work out which bitmap page contains the bit for the page number in question.
>> 2. Read that bitmap page.
>> 3. Indicate the status of that bit within that page.
>>
>> However, that's not what the function actually does. Instead, it does this:
>>
>> 1. Go examine the overflow page and see whether hasho_prevblkno. If
>> so, claim that the bit is set in the bitmap; if not, claim that it
>> isn't.
>> 2. Work out which bitmap page contains the bit for the page number in question.
>> 3. But don't look at it. Instead, tell the user which bitmap page and
>> bit you would have looked at, but instead of returning the status of
>> that bit, return the value you computed in step 1.
>>
>> I do not think this can be the right approach.
>
> Yes, It is not a right approach. As I mentioned in [1], the overflow
> page being freed is completely filled with zero values which means it
> is not in a readable state. So, we won't be able to examine a free
> overflow page. Considering these facts, I would take following
> approach,
>
> 1) Check if an overflow page is a new page. If so, read a bitmap page
> to confirm if a bit corresponding to this overflow page is clear or
> not. For this, I would first add Assert statement to ensure that the
> bit is clear and if it is, then set the statusbit as false indicating
> that the page is free.
>
> 2) In case if an overflow page is not new, first verify if it is
> really an overflow page and if so, check if the bit corresponding to
> it in the bitmap page is SET. If so, set the statusbit as true; If
> not, we would see an assertion failure happening.

I think this is complicated and not what anybody wants. I think you
should do exactly what I said above: return true if the bit is set in
the bitmap, and false if it isn't. Full stop. Don't read or do
anything with the underlying page. Only read the bitmap page.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Stephen Frost 2017-02-07 13:39:45 GSoC 2017 - LAST CALL
Previous Message Stephen Frost 2017-02-07 13:35:37 Re: GSoC 2017