Re: Excessive CPU usage in StandbyReleaseLocks()

From: Andres Freund <andres(at)anarazel(dot)de>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Thomas Munro <thomas(dot)munro(at)enterprisedb(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Excessive CPU usage in StandbyReleaseLocks()
Date: 2018-06-19 17:23:08
Message-ID: 20180619172308.fdc23eswyal7ehxy@alap3.anarazel.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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(at)anarazel(dot)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(at)anarazel(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Geoghegan 2018-06-19 17:23:29 Re: Fast default stuff versus pg_upgrade
Previous Message Tom Lane 2018-06-19 17:19:32 Re: Fast default stuff versus pg_upgrade