On Fri, Jan 21, 2011 at 13:56, Tatsuo Ishii is...@postgresql.org 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
Itagaki Takahiro itagaki.takah...@gmail.com writes:
On Fri, Jan 21, 2011 at 13:56, Tatsuo Ishii is...@postgresql.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
On Fri, Jan 21, 2011 at 10:35 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Itagaki Takahiro itagaki.takah...@gmail.com writes:
On Fri, Jan 21, 2011 at 13:56, Tatsuo Ishii is...@postgresql.org wrote:
Anyone has better idea? Tom dislikes my patch but I don't know how to
deal with it.
There was
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
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 and if it's not set, it
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 and if it's not set, it
Tatsuo Ishii is...@postgresql.org 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
Tatsuo Ishii is...@postgresql.org 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
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 and if it's not set, it
On Thu, May 13, 2010 at 8:20 PM, Tatsuo Ishii is...@postgresql.org 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
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
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 shared
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
13 matches
Mail list logo
