Re: pg_terminate_backend idea - Mailing list pgsql-hackers

From Magnus Hagander
Subject Re: pg_terminate_backend idea
Date
Msg-id 6BCB9D8A16AC4241919521715F4D8BCE094559@algol.sollentuna.se
Whole thread Raw
In response to pg_terminate_backend idea  ("Magnus Hagander" <mha@sollentuna.net>)
Responses Re: pg_terminate_backend idea
List pgsql-hackers
> >> In any case the correct way to solve the problem is to find out
> >> what's being left corrupt by SIGTERM, rather than install more
> >> messiness in order to avoid facing the real issue ...
>
> > That is unfortunatly way over my head. And it doesn't seem like
> > anybody who actually has what it takes to do the "proper
> solution" is
> > interested in doing it.
>
> A test case --- even one that fails only a small percentage
> of the time
> --- would make things far easier.  So far all I've seen are
> very vague reports, and it's impossible to do anything about
> it without more info.

Very well. Let me try putting it like this, then:

Assuming we don't get such a case, and a chance to fix it, before 8.1
(while still hoping we will get it fixed properly, we can't be sure, can
we? If we were, it'd be fixed already). In this case, will you consider
such a kludgy solution as a temporary fix to resolve a problem that a
lot of users are having? And then plan to have it removed once sending
SIGTERM directly to a backend can be considered safe?


//Magnus


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: [PATCHES] Removing Kerberos 4
Next
From: Chris Campbell
Date:
Subject: Re: Problem with dblink regression test