Re: Provide a pg_truncate_freespacemap function - Mailing list pgsql-hackers

From Stephen Frost
Subject Re: Provide a pg_truncate_freespacemap function
Date
Msg-id ZejD7P+i2ZPDw8O/@tamriel.snowman.net
Whole thread Raw
In response to Provide a pg_truncate_freespacemap function  (Ronan Dunklau <ronan.dunklau@aiven.io>)
Responses Re: Provide a pg_truncate_freespacemap function
List pgsql-hackers
Greetings,

* Ronan Dunklau (ronan.dunklau@aiven.io) wrote:
> As we are currently experiencing a FSM corruption issue [1], we need to
> rebuild FSM when we detect it.

Ideally, we'd figure out a way to pick up on this and address it without
the user needing to intervene, however ...

> I noticed we have something to truncate a visibility map, but nothing for the
> freespace map, so I propose the attached (liberally copied from the VM
> counterpart) to allow to truncate a FSM without incurring downtime, as
> currently our only options are to either VACUUM FULL the table or stop the
> cluster and remove the FSM manually.

I agree that this would generally be a useful thing to have.

> Does that seem correct ?

Definitely needs to have a 'REVOKE ALL ON FUNCTION' at the end of the
upgrade script, similar to what you'll find at the bottom of
pg_visibility--1.1.sql in the tree today, otherwise anyone could run it.

Beyond that, I'd suggest a function-level comment above the definition
of the function itself (which is where we tend to put those- not at the
point where we declare the function).

Thanks!

Stephen

Attachment

pgsql-hackers by date:

Previous
From: a.imamov@postgrespro.ru
Date:
Subject: Re: Potential issue in ecpg-informix decimal converting functions
Next
From: Heikki Linnakangas
Date:
Subject: Re: Confine vacuum skip logic to lazy_scan_skip