On 4/14/23 8:30 AM, Robert Haas wrote:
> On Thu, Apr 13, 2023 at 11:06 PM Laurenz Albe <laurenz.albe@cybertec.at> wrote:
>> I am not against this in principle, but I know that there are people using
>> this parameter; see the discussion linked in
>>
>> https://postgr.es/m/E1jkzxE-0006Dw-Dg@gemulon.postgresql.org
>>
>> I can't say if they have a good use case for that parameter or not.
>
> Yeah, I feel similarly. Actually, personally I have no evidence, not
> even an anecdote, suggesting that this parameter is in use, but I'm a
> bit skeptical of any consensus of the form "no one is using X,"
> because there sure are a lot of people running PostgreSQL and they
> sure do a lot of things. Some more justifiably than others, but often
> people have surprisingly good excuses for doing stuff that sounds
> bizarre when you first hear about it, and it doesn't seem totally
> impossible that somebody could have found a way to get value out of
> this.
Let me restate [1] in a different way.
Using a large enough dataset, I did qualitatively look at overall usage
of both "vacuum_defer_cleanup_age" and compared to
"hot_standby_feedback", given you can use both to accomplish similar
outcomes. The usage of "vacuum_defer_cleanup_age" was really minimal, in
fact approaching "0", whereas "hot_standby_feedback" had significant
adoption.
I'm not saying that "we should remove a setting just because it's not
used" or that it may not have utility -- I'm saying that we can remove
the setting given:
1. We know that using this setting incorrectly (which can be done fairly
easily) can cause significant issues
2. There's another setting that can accomplish similar goals that's much
safer
3. The setting itself is not widely used
It's the combination of all 3 that led to my conclusion. If it were just
(1), I'd lean more strongly towards trying to fix it first.
> However, I suspect that there aren't many such people, and I think the
> setting is a kludge, so I support removing it. Maybe we'll find out
> that we ought to add something else instead, like a limited delimited
> in time rather than in XIDs. Or maybe the existing facilities are good
> enough. But as Peter rightly says, XID age is likely a poor proxy for
> whatever people really care about, so I don't think continuing to have
> a setting that works like that is a good plan.
That seems like a good eventual outcome.
Thanks,
Jonathan
[1]
https://www.postgresql.org/message-id/bf42784f-4d57-0a3d-1a06-ffac1a09318c%40postgresql.org