Re: Proposal: Log inability to lock pages during vacuum

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Andres Freund <andres(at)2ndquadrant(dot)com>
Cc: Jim Nasby <Jim(dot)Nasby(at)bluetreble(dot)com>, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, Greg Stark <stark(at)mit(dot)edu>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Proposal: Log inability to lock pages during vacuum
Date: 2014-11-12 17:53:41
Message-ID: CA+Tgmob1WRR+jwZ=Ec0Nd3cf8iG_dsN0v1YUemvbzbcQd-0OtA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, Nov 12, 2014 at 12:37 PM, Andres Freund <andres(at)2ndquadrant(dot)com> wrote:
> 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.

That's a little harsh, but I agree. Producing a warning here is just
going to be log-spam. We've had this behavior for years and - to my
knowledge - we have not got one complaint that can be attributed to
this feature. What used to happen is that VACUUM would get stuck for
minutes, hours, or days trying to vacuum a table because of an open
cursor, and people did complain about that. It was a serious nuisance
that is now gone. The entire argument in favor of some change here is
"even though a careful theoretical analysis indicates that this is
safe, even though it solved a real problem that was hurting our users,
and even though we have no evidence whatsoever that the change is
hurting anybody in any way whatsoever, the lack of instrumentation
means that it could possibly be hurting somebody and we wouldn't
know."

That is, of course, quite true, but you could apply the same argument
to lots of patches. It would usually be a waste of time because most
of the patches we think are good actually ARE good - but of course,
every once in a while you would find a real problem that had been
overlooked.

Maybe the right thing here is not to make any change to the source
code *at all* but to patch his own copy and try to come up with a
reproducible test case where this is actually a problem. Then, if
there is a problem, we could actually fix it.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Fujii Masao 2014-11-12 18:01:36 Re: alter user set local_preload_libraries.
Previous Message Andres Freund 2014-11-12 17:47:55 Re: what does this mean: "running xacts with xcnt == 0"