Re: FSM corruption leading to errors - Mailing list pgsql-hackers

From Tom Lane
Subject Re: FSM corruption leading to errors
Date
Msg-id 16429.1477334780@sss.pgh.pa.us
Whole thread Raw
In response to Re: FSM corruption leading to errors  (Alvaro Herrera <alvherre@2ndquadrant.com>)
List pgsql-hackers
Alvaro Herrera <alvherre@2ndquadrant.com> writes:
> Tom Lane wrote:
>> Also, we could at least discount the FSM root page and first intermediate
>> page, no?  That is, the upper limit could be
>>
>> pg_relation_size(oid::regclass, 'fsm') / 2 - 2*current_setting('block_size')::BIGINT
>>
>> I think this is a worthwhile improvement because it reduces the time spent
>> on small relations.  For me, the query as given takes 9 seconds to examine
>> the regression database, which seems like a lot.  Discounting two pages
>> reduces that to 20 ms.

> Hah, good one.  We spent some time thinking about subtracting some value
> to make the value more accurate but it didn't occur to me to just use
> constant two.

I got the arithmetic wrong in the above, it should be like

(pg_relation_size(oid::regclass, 'fsm') - 2*current_setting('block_size')::BIGINT) / 2

With that, the runtime on HEAD's regression DB is about 700 ms, which is
still a nice win over 9000 ms.

I've put up draft wiki pages about these two problems at

https://wiki.postgresql.org/wiki/Free_Space_Map_Problems
https://wiki.postgresql.org/wiki/Visibility_Map_Problems

(thanks to Michael Paquier for initial work on the first one).
They're meant to be reasonably generic about FSM/VM problems
rather than only being about our current bugs.  Please review.
        regards, tom lane



pgsql-hackers by date:

Previous
From: Alvaro Herrera
Date:
Subject: Re: [COMMITTERS] pgsql: Remove extra comma at end of enum list
Next
From: Robert Haas
Date:
Subject: Re: Press Release Draft - 2016-10-27 Cumulative Update