Re: Provide a pg_truncate_freespacemap function

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

In response to

Responses

Browse pgsql-hackers by date

  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