From: | Stephen Frost <sfrost(at)snowman(dot)net> |
---|---|
To: | Ronan Dunklau <ronan(dot)dunklau(at)aiven(dot)io> |
Cc: | pgsql-hackers(at)lists(dot)postgresql(dot)org |
Subject: | Re: Provide a pg_truncate_freespacemap function |
Date: | 2024-03-06 19:28:44 |
Message-ID: | ZejD7P+i2ZPDw8O/@tamriel.snowman.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Greetings,
* Ronan Dunklau (ronan(dot)dunklau(at)aiven(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Heikki Linnakangas | 2024-03-06 19:55:21 | Re: Confine vacuum skip logic to lazy_scan_skip |
Previous Message | a.imamov | 2024-03-06 19:12:46 | Re: Potential issue in ecpg-informix decimal converting functions |