Re: FSM corruption leading to errors

From: Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Michael Paquier <michael(dot)paquier(at)gmail(dot)com>, Jim Nasby <Jim(dot)Nasby(at)bluetreble(dot)com>, Pavan Deolasee <pavan(dot)deolasee(at)gmail(dot)com>, Heikki Linnakangas <hlinnaka(at)iki(dot)fi>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: FSM corruption leading to errors
Date: 2016-10-24 18:06:55
Message-ID: 20161024180655.6pbbpmjjaeunbd2r@alvherre.pgsql
Views: Raw Message | Whole Thread | Download mbox
Thread:
Lists: pgsql-hackers

Tom Lane wrote:

> Ah, scratch that, after rereading the FSM README I see it's correct,
> because there's a binary tree within each page; I'd only remembered
> that there was a search tree of pages.
>
> 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.

--
Álvaro Herrera https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Alvaro Herrera 2016-10-24 18:26:33 Re: Renaming of pg_xlog and pg_clog
Previous Message Jonathan Katz 2016-10-24 17:14:57 Press Release Draft - 2016-10-27 Cumulative Update