On Mon, Jun 30, 2014 at 11:26 PM, Kyotaro HORIGUCHI <horiguchi.kyot...@lab.ntt.co.jp> wrote: >> 2. I think it would be reasonable to try to kill off the connection >> without notifying the client if we're unable to send the data to the >> client in a reasonable period of time. But I'm unsure what "a >> reasonable period of time" means. This patch would basically do it >> after no delay at all, which seems like it might be too aggressive. >> However, I'm not sure. > > 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. But they are not going to want to have to take a second action to kill the backend - killing it once should be sufficient. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers