Re: Proposal: Log inability to lock pages during vacuum

Поиск
Список
Период
Сортировка
От Andres Freund
Тема Re: Proposal: Log inability to lock pages during vacuum
Дата
Msg-id 20141112173746.GD13473@awork2.anarazel.de
обсуждение исходный текст
Ответ на Re: Proposal: Log inability to lock pages during vacuum  (Jim Nasby <Jim.Nasby@BlueTreble.com>)
Ответы Re: Proposal: Log inability to lock pages during vacuum  (Robert Haas <robertmhaas@gmail.com>)
Список pgsql-hackers
On 2014-11-12 11:34:04 -0600, Jim Nasby wrote:
> On 11/11/14, 2:01 AM, Andres Freund wrote:
> >On 2014-11-10 19:36:18 -0600, Jim Nasby wrote:
> >>Towards that simple end, I'm a bit torn. My preference would be to
> >>simply log, and throw a warning if it's over some threshold. I believe
> >>that would give the best odds of getting feedback from users if this
> >>isn't as uncommon as we think.
> >
> >I'm strongly against a warning. We have absolutely no sane way of tuning
> >that. We'll just create a pointless warning that people will get
> >confused about and that they'll have to live with till the next release.
> 
> To clarify: I'm only suggesting we issue a warning if we have to skip some significant number of pages; say 5 or
0.01%of the table, whichever is greater. That's aimed directly at the goal of letting us know if this is actually a
problemor not.
 

Meh. You have a 5 page relation and it'll trigger quite easily. And it's
absolutely harmless.

> The reason I'm inclined to do the warning is because I don't think people will notice this otherwise. If this really
isn'ta problem then it won't matter; if it's a *big* problem then we'll at least know about it.
 
> 
> I'm thinking of an undocumented GUC to control the threshold, but I assume no one else would be on board with that?

Stop overdesigning this.

Add it to the existing mesage and let us be done with this. This thread
has already wasted far too much time.

Greetings,

Andres Freund

-- Andres Freund                       http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training &
Services



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

Предыдущее
От: Jim Nasby
Дата:
Сообщение: Re: Proposal: Log inability to lock pages during vacuum
Следующее
От: Robert Haas
Дата:
Сообщение: Re: pg_background (and more parallelism infrastructure patches)