On 2016-04-12 10:54 AM, Robert Haas wrote:
> On Tue, Apr 12, 2016 at 8:59 AM, Justin Clift <justin@postgresql.org> wrote:
>> On 12 Apr 2016, at 13:37, Robert Haas <robertmhaas@gmail.com> wrote:
>>> On Tue, Apr 12, 2016 at 3:21 AM, Magnus Hagander <magnus@hagander.net> wrote:
>>>> I think that may turn out to be one of those "hidden gems" of this release.
>>>> As in being the one that nobody talks about now, but then a few years down
>>>> the road it's the one that everybody talks about. But it's somewhat hard to
>>>> explain to people who (1) don't know how the system really works (though
>>>> that would count for things like snapshot too old as well) or (2) actually
>>>> have run into the current problem (why hey, that's also the same with
>>>> snapshot too old)
>>>
>>> Agreed. Unfortunately, for many people, the first time they really
>>> become aware of autovacuum is when all of their tables hit the freeze
>>> threshold for the first time. And this doesn't help with that. You
>>> still have to scan everything after 200 million transactions; it's
>>> just that you no longer have to do it again every 200 million
>>> transactions after that. I still think it's a great feature, though.
>>
>> Er... we don't provide a warning ahead of time in the logs or something?
>
> No. That would be a little strange, honestly. I have to assume that
> many wraparound vacuums go totally unnoticed; how would you
> distinguish the ones that are likely to annoy somebody from the other
> ones?
I suggest providing a config option for those warnings, if there isn't one
already. Global plus override per table etc. The option says we only log the
warnings if the wraparound vacuum is likely to take more than a certain amount
of time, and pick something reasonable for that default time. Or to generalize,
have a config saying what to do if a wraparound vacuum is coming up soon,
including what amount of estimated time may be considered inconvenient. --
Darren Duncan
