Le dimanche 21 juillet 2024, 07:39:13 UTC+2 Tom Lane a écrit :
> Fujii Masao 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.
>
Fujii Masao 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 no
On 2024/03/07 16:59, Ronan Dunklau wrote:
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.
Thanks !
Does that seem correct ?
Definitely needs to have a 'REVOKE ALL ON FUNCTION' at the end of the
upgrade script,
here we declare the function).
Thank you for the review. Here is an updated patch for both of those.
Best regards,
--
Ronan>From 812061b47443ce1052f65ba2867223f9db2cfa18 Mon Sep 17 00:00:00 2001
From: Ronan Dunklau
Date: Fri, 1 Mar 2024 08:57:49 +0100
Subject: [PATCH] P
Greetings,
* Ronan Dunklau (ronan.dunk...@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
--
Ronan Dunklau
>From b3e28e4542311094ee7177b39cc9cdf3672d1b55 Mon Sep 17 00:00:00 2001
From: Ronan Dunklau
Date: Fri, 1 Mar 2024 08:57:49 +0100
Subject: [PATCH] Provide a pg_truncate_freespacemap function.
Similar to the pg_truncate_visibilitymap function, this one allows to
avoid downtime to
