On Fri, Jan 21, 2011 at 10:35 AM, Tom Lane wrote:
> Itagaki Takahiro writes:
>> On Fri, Jan 21, 2011 at 13:56, Tatsuo Ishii 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 post
Itagaki Takahiro writes:
> On Fri, Jan 21, 2011 at 13:56, Tatsuo Ishii 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 i
On Fri, Jan 21, 2011 at 13:56, Tatsuo Ishii wrote:
>> Here is the patch to implement the feature.
>>
>> 1) pg_terminate_backend() sends SIGUSR1 signal rather than SIGTERM to
>> the target backend.
>> 2) The infrastructure used for message passing is
>> storage/ipc/procsignal.c The new messag
> Here is the patch to implement the feature.
>
> 1) pg_terminate_backend() sends SIGUSR1 signal rather than SIGTERM to
>the target backend.
> 2) The infrastructure used for message passing is
>storage/ipc/procsignal.c The new message type for ProcSignalReason
>is "PROCSIG_TERMNINATE_B
> Tatsuo Ishii writes:
>> Comments are welcome.
>
> This is a bad idea. It makes an already-poorly-tested code path
> significantly more fragile, in return for nothing of value.
Are you saying that procsignal.c is the already-poorly-tested one? If
so, why?
As for "value", I have already explai
Tatsuo Ishii writes:
> Comments are welcome.
This is a bad idea. It makes an already-poorly-tested code path
significantly more fragile, in return for nothing of value.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make chan
>> >> Seems reasonable. Does the victim backend currently know why it has been
>> >> killed?
>> >
>> > I don't think so.
>> >
>> > One idea is postmaster sets a flag in the shared memory area
>> > indicating it rceived SIGTERM before forwarding the signal to
>> > backends.
>> >
>> > Backend check t
>> >> Seems reasonable. Does the victim backend currently know why it has been
>> >> killed?
>> >
>> > I don't think so.
>> >
>> > One idea is postmaster sets a flag in the shared memory area
>> > indicating it rceived SIGTERM before forwarding the signal to
>> > backends.
>> >
>> > Backend check t
> >> Seems reasonable. Does the victim backend currently know why it has been
> >> killed?
> >
> > I don't think so.
> >
> > One idea is postmaster sets a flag in the shared memory area
> > indicating it rceived SIGTERM before forwarding the signal to
> > backends.
> >
> > Backend check the flag an
On Thu, May 13, 2010 at 8:20 PM, Tatsuo Ishii wrote:
>> > Maybe we could make PostgreSQL a little bit smarter so that it returns
>> > a different code than 57P01 when killed by pg_terminate_backend().
>>
>> Seems reasonable. Does the victim backend currently know why it has been
>> killed?
>
> I d
> > Maybe we could make PostgreSQL a little bit smarter so that it returns
> > a different code than 57P01 when killed by pg_terminate_backend().
>
> Seems reasonable. Does the victim backend currently know why it has been
> killed?
I don't think so.
One idea is postmaster sets a flag in the sha
Tatsuo Ishii wrote:
> If a backend killed by pg_terminate_backend(), the backend returns
> 57P01 which is identical to the one when it's killed by postmaster.
>
> Problem is, pgpool-II needs to trigger failover if postmaster goes
> down because apparently pgpool-II cannot use the PostgreSQL server
Hi,
If a backend killed by pg_terminate_backend(), the backend returns
57P01 which is identical to the one when it's killed by postmaster.
Problem is, pgpool-II needs to trigger failover if postmaster goes
down because apparently pgpool-II cannot use the PostgreSQL server
anymore.
On the otherha
13 matches
Mail list logo
