Le dimanche 21 juillet 2024, 07:39:13 UTC+2 Tom Lane a écrit : > Fujii Masao <masao.fu...@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. >
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
