Re: Escaping from blocked send() reprised.

From: Kyotaro HORIGUCHI <horiguchi(dot)kyotaro(at)lab(dot)ntt(dot)co(dot)jp>
To: robertmhaas(at)gmail(dot)com
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Escaping from blocked send() reprised.
Date: 2014-07-04 09:54:04
Message-ID: 20140704.185404.135768374.horiguchi.kyotaro@lab.ntt.co.jp
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hello, thank you for keeping this discussion moving.

> > I think there's no such a reasonable time. The behavior might
> > should be determined from another point.. On alternative would be
> > let pg_terminate_backend() have a parameter instructing force
> > shutodwn (how to propagate it?), or make a forced shutdown on
> > duplicate invocation of pg_terminate_backend().
>
> Well, I think that when people call pg_terminate_backend() just once,
> they expect it to kill the target backend. I think people will
> tolerate a short delay, like a few seconds; after all, there's no
> guarantee, even today, that the backend will hit a
> CHECK_FOR_INTERRUPTS() in less than a few hundred milliseconds.

Sure.

> But they are not going to want to have to take a second action
> to kill the backend - killing it once should be sufficient.

Hmm, it sounds persuasive. Well, do you think they tolerate
-force option? (Even though its technical practicality is not
clear)

regards,

--
Kyotaro Horiguchi
NTT Open Source Software Center

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Fabien COELHO 2014-07-04 09:59:23 Re: gaussian distribution pgbench
Previous Message Andres Freund 2014-07-04 09:50:17 No toast table for pg_shseclabel but for pg_seclabel