Re: Excessive CPU usage in StandbyReleaseLocks()

Поиск
Список
Период
Сортировка
От Andres Freund
Тема Re: Excessive CPU usage in StandbyReleaseLocks()
Дата
Msg-id 20180619172308.fdc23eswyal7ehxy@alap3.anarazel.de
обсуждение исходный текст
Ответ на Re: Excessive CPU usage in StandbyReleaseLocks()  (Robert Haas <robertmhaas@gmail.com>)
Ответы Re: Excessive CPU usage in StandbyReleaseLocks()  (Tom Lane <tgl@sss.pgh.pa.us>)
Список 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 по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: Fast default stuff versus pg_upgrade
Следующее
От: Peter Geoghegan
Дата:
Сообщение: Re: Fast default stuff versus pg_upgrade