From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Michael Paquier <michael(dot)paquier(at)gmail(dot)com> |
Cc: | 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 16:04:48 |
Message-ID: | 18695.1477325088@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Michael Paquier <michael(dot)paquier(at)gmail(dot)com> writes:
> Release notes refer to this page for methods to fix corrupted instances:
> https://wiki.postgresql.org/wiki/Free_Space_Map_Problems
> I just typed something based on Pavan's upper method, feel free to
> jump in and improve it as necessary.
Thanks for drafting that, but isn't the query wrong?
Specifically the bit about
SELECT blkno, pg_freespace(oid::regclass, blkno)
FROM generate_series(pg_relation_size(oid::regclass) / current_setting('block_size')::BIGINT,
pg_relation_size(oid::regclass, 'fsm') / 2) AS blkno
It looks to me like this is approximating the highest block number that
could possibly have an FSM entry as size of the FSM fork (in bytes)
divided by 2. But the FSM stores one byte per block. There is overhead
for the FSM search tree, but in a large relation it's not going to be as
much as a factor of 2. So I think that to be conservative we need to
drop the "/ 2". Am I missing something?
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Pavan Deolasee | 2016-10-24 16:15:47 | Re: FSM corruption leading to errors |
Previous Message | Robert Haas | 2016-10-24 15:57:27 | Re: Patch: Implement failover on libpq connect level. |