Re: Provide a pg_truncate_freespacemap function

Le dimanche 21 juillet 2024, 07:39:13 UTC+2 Tom Lane a écrit :
> Fujii Masao <masao(dot)fujii(at)oss(dot)nttdata(dot)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.
>

Sorry for the late reply, as I was not available during the late summer.

> 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.)

Now that the other patch for self-healing is in, I agree it may not be that
useful. I'm withdrawing the patch and will keep it in mind if we encounter
other FSM issues in the future.

Best regards,

--
Ronan Dunklau