Re: Provide a pg_truncate_freespacemap function

Поиск
Список
Период
Сортировка
От Stephen Frost
Тема Re: Provide a pg_truncate_freespacemap function
Дата
Msg-id ZejD7P+i2ZPDw8O/@tamriel.snowman.net
обсуждение исходный текст
Ответ на Provide a pg_truncate_freespacemap function  (Ronan Dunklau <ronan.dunklau@aiven.io>)
Ответы Re: Provide a pg_truncate_freespacemap function  (Ronan Dunklau <ronan.dunklau@aiven.io>)
Список 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

Вложения

В списке pgsql-hackers по дате отправления:

Предыдущее
От: a.imamov@postgrespro.ru
Дата:
Сообщение: Re: Potential issue in ecpg-informix decimal converting functions
Следующее
От: Heikki Linnakangas
Дата:
Сообщение: Re: Confine vacuum skip logic to lazy_scan_skip