Re: multixacts woes

Поиск
Список
Период
Сортировка
От Josh Berkus
Тема Re: multixacts woes
Дата
Msg-id 5550E5D1.1070308@agliodbs.com
обсуждение исходный текст
Ответ на multixacts woes  (Robert Haas <robertmhaas@gmail.com>)
Ответы Re: multixacts woes  (Alvaro Herrera <alvherre@2ndquadrant.com>)
Re: multixacts woes  ("Joshua D. Drake" <jd@commandprompt.com>)
Список pgsql-hackers
On 05/11/2015 09:54 AM, Robert Haas wrote:
> OK, I have made this change.  Barring further trouble reports, this
> completes the multixact work I plan to do for the next release.  Here
> is what is outstanding:
> 
> 1. We might want to introduce a GUC to control the point at which
> member offset utilization begins clamping
> autovacuum_multixact_freeze_max_age.  It doesn't seem wise to do
> anything about this before pushing a minor release out.  It's not
> entirely trivial, and it may be helpful to learn more about how the
> changes already made work out in practice before proceeding.  Also, we
> might not back-patch this anyway.

-1 on back-patching a new GUC.  People don't know what to do with the
existing multixact GUCs, and without an age(multixact) function
built-in, any adjustments a user tries to make are likely to do more
harm than good.

In terms of adding a new GUC in 9.5: can't we take a stab at auto-tuning
this instead of adding a new GUC?  We already have a bunch of freezing
GUCs which fewer than 1% of our user base has any idea how to set.

> 2. The recent changes adjust things - for good reason - so that the
> safe threshold for multixact member creation is advanced only at
> checkpoint time.  This means it's theoretically possible to have a
> situation where autovacuum has done all it can, but because no
> checkpoint has happened yet, the user can't create any more
> multixacts.  Thanks to some good work by Thomas, autovacuum will
> realize this and avoid spinning uselessly over every table in the
> system, which is good, but you're still stuck with errors until the
> next checkpoint.  Essentially, we're hoping that autovacuum will clean
> things up far enough in advance of hitting the threshold where we have
> to throw an error that a checkpoint will intervene before the error
> starts happening.  It's possible we could improve this further, but I
> think it would be unwise to mess with it right now.  It may be that
> there is no real-world problem here.

Given that our longest possible checkpoint timeout is an hour, is it
even hypotethically possible that we would hit a limit in that time?
How many mxact members are we talking about?

-- 
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Andres Freund
Дата:
Сообщение: Re: a fast bloat measurement tool (was Re: Measuring relation free space)
Следующее
От: Alvaro Herrera
Дата:
Сообщение: Re: multixacts woes