From: Tom Lane <tgl@sss.pgh.pa.us>
To: Fujii Masao <masao.fujii@oss.nttdata.com>
cc: Ronan Dunklau <ronan.dunklau@aiven.io>, Stephen Frost <sfrost@snowman.net>,
        pgsql-hackers@lists.postgresql.org
Subject: Re: Provide a pg_truncate_freespacemap function
In-reply-to: <8acb1f83-2945-42cf-8795-780c94bbed36@oss.nttdata.com>
References: <5446938.Sb9uPGUboI@aivenlaptop> <ZejD7P+i2ZPDw8O/@tamriel.snowman.net> <4331161.ejJDZkT8p0@aivenlaptop> <8acb1f83-2945-42cf-8795-780c94bbed36@oss.nttdata.com>
Comments: In-reply-to Fujii Masao <masao.fujii@oss.nttdata.com>
	message dated "Sun, 21 Jul 2024 13:51:56 +0900"
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-ID: <535626.1721540353.1@sss.pgh.pa.us>
Content-Transfer-Encoding: 8bit
Date: Sun, 21 Jul 2024 01:39:13 -0400
Message-ID: <535627.1721540353@sss.pgh.pa.us>
Archived-At: <https://www.postgresql.org/message-id/535627.1721540353%40sss.pgh.pa.us>
Precedence: bulk

Fujii Masao <masao.fujii@oss.nttdata.com> writes:
>> Le mercredi 6 mars 2024, 20:28:44 CET Stephen Frost a écrit :
>>> I agree that this would generally be a useful thing to have.

Personally, I want to push back on whether this has any legitimate
use-case.  Even if the FSM is corrupt, it should self-heal over
time, and I'm not seeing the argument why truncating it would
speed convergence towards correct values.  Worse, in the interim
where you don't have any FSM, you will suffer table bloat because
insertions will be appended at the end of the table.  So this
looks like a foot-gun, and the patch's lack of user-visible
documentation surely does nothing to make it safer.

(The analogy to pg_truncate_visibility_map seems forced.
If you are in a situation with a trashed visibility map,
you are probably getting wrong query answers, and truncating
the map will make that better.  But a trashed FSM doesn't
result in incorrect output, and zeroing it will make things
worse not better.)

			regards, tom lane