Re: Proposal: Log inability to lock pages during vacuum - Mailing list pgsql-hackers

From Andres Freund
Subject Re: Proposal: Log inability to lock pages during vacuum
Date
Msg-id 20141112173746.GD13473@awork2.anarazel.de
Whole thread Raw
In response to Re: Proposal: Log inability to lock pages during vacuum  (Jim Nasby <Jim.Nasby@BlueTreble.com>)
Responses Re: Proposal: Log inability to lock pages during vacuum  (Robert Haas <robertmhaas@gmail.com>)
List 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 by date:

Previous
From: Jim Nasby
Date:
Subject: Re: Proposal: Log inability to lock pages during vacuum
Next
From: Robert Haas
Date:
Subject: Re: pg_background (and more parallelism infrastructure patches)