On 2025/06/04 4:32, Sami Imseih wrote:
>> On Tue, Jun 03, 2025 at 10:57:11AM +0200, Michael Banck wrote:
>>> On Tue, Jun 03, 2025 at 05:25:40PM +0900, Shinya Kato wrote:
>>>> I surely think adding log_autoanalyze_min_duration is simpler and
>>>> shorter, but the reason I chose this GUC name is for consistency with
>>>> other autovacuum parameters. Existing autovacuum parameters that have
>>>> separate settings for vacuum and analyze operations follow the pattern
>>>> autovacuum_{vacuum|analyze}_*.
>>>> https://www.postgresql.org/docs/devel/runtime-config-vacuum.html#RUNTIME-CONFIG-AUTOVACUUM
>>>
>>> Right, but the GUCs that directly affect either vacuum or autovacuum
>>> behaviour need the qualification (and then vacuum/analyze on top of it).
>>> I think we have less constraints with the logging GUC and do not need to
>>> mirror the behaviorial GUCs at all costs. But again, that is just my two
>>> cents.
>>
>> I lean towards log_autovacuum_{vacuum|analyze}_min_duration. If
>> log_autovacuum_min_duration didn't exist, that's probably the naming scheme
>> we'd go with. However, I'm not sure we can get away with renaming
>> log_autovacuum_min_duration. Presumably we'd need to at least keep it
>> around as a backward-compatibility GUC, and its behavior would probably
>> change, too
>
> I think deprecating a GUC like log_autovacuum_min_duration would be quite
> difficult.
Also deprecating the log_autovacuum_min_duration reloption might be tricky.
If we remove support for it in v19, how should pg_dump handle tables with
this option set from older versions? Should it translate it into both
log_autovacuum_vacuum_min_duration and log_autovacuum_analyze_min_duration
during dump? Would pg_upgrade run into the same issue?
Regards,
--
Fujii Masao
NTT DATA Japan Corporation
