> 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. If you are okay with this approach, please let me know I will share you an updated patch. Thanks. [1]- https://www.postgresql.org/message-id/CAE9k0PkiwT0qD3fdruU8bgAjTpzJpnqcT0XNWnnKxxFbogbL9A%40mail.gmail.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
