Re: Excessive CPU usage in StandbyReleaseLocks() - Mailing list pgsql-hackers

From Andres Freund
Subject Re: Excessive CPU usage in StandbyReleaseLocks()
Date
Msg-id 20180619172308.fdc23eswyal7ehxy@alap3.anarazel.de
Whole thread Raw
In response to Re: Excessive CPU usage in StandbyReleaseLocks()  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: Excessive CPU usage in StandbyReleaseLocks()
List pgsql-hackers
On 2018-06-19 13:05:48 -0400, Robert Haas wrote:
> On Tue, Jun 19, 2018 at 1:01 PM, Andres Freund <andres@anarazel.de> wrote:
> > On 2018-06-19 10:45:04 -0400, Robert Haas wrote:
> >> On Tue, Jun 19, 2018 at 2:30 AM, Andres Freund <andres@anarazel.de> wrote:
> >> > This should be a PANIC imo.
> >>
> >> -1.  As a developer, I would prefer PANIC.  But as an end-user, I
> >> would much rather have replay continue (with possible problems) than
> >> have it stopped cold in its tracks with absolutely nothing that I as
> >> the administrator can do to fix it.  We should be building this
> >> product for end users.
> >
> > Except that that just means the end-user will have an undebuggable
> > problem at their hand. Which will affect them as well.
> 
> I agree, but my guess is that a PANIC will affect them more.

Sure, in the short term. I think our disagreement is based on the a
different viewpoint: I think users are served better if a problem is
surfaced as close to the origin, because that makes quick diagnosis and
fix possible - even if that means sometimes erroring out in cases where
we could have just limped on without causing noticed problems.  You
think that trying to limp along as long as possible is good, because
that removes immediate pain from the user (and then prevents the user
from redirecting the pain to you).


> I don't expect you to agree with my vote, but I stand by it.

Yea, I didn't expect (but hoped!) to change your mind... ;)

Greetings,

Andres Freund


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Fast default stuff versus pg_upgrade
Next
From: Peter Geoghegan
Date:
Subject: Re: Fast default stuff versus pg_upgrade