Michael Paquier <michael.paqu...@gmail.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 -- Sent via pgsql-hackers mailing list (firstname.lastname@example.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers