Re: How to know killed by pg_terminate_backend

On Fri, Jan 21, 2011 at 10:35 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Itagaki Takahiro <itagaki(dot)takahiro(at)gmail(dot)com> writes:
>> On Fri, Jan 21, 2011 at 13:56, Tatsuo Ishii <ishii(at)postgresql(dot)org> wrote:
>>> Anyone has better idea? Tom dislikes my patch but I don't know how to
>>> deal with it.
>
>> There was another design in the past discussion:
>> One idea is postmaster sets a flag in the shared memory area
>> indicating it rceived SIGTERM before forwarding the signal to
>> backends.
>
>> Is it enough for your purpose and do we think it is more robust way?
>
> To put this as briefly as possible: I don't want to add even one line of
> code to distinguish pg_terminate_backend from database-wide shutdown.
> That function should be a last-ditch tool, not something used on a daily
> basis.  So I disagree with the premise as much as with any particular
> implementation.

Well, that seems awfully unfriendly.

Frequency of use is beside the point - people are trying to write
client applications - like pgpool-II - that understand the behavior of
PG. If we send the same error code in two different situations with
different behaviors, such applications have to do so silly workarounds
to figure out what really happened.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company