Prev: pg_upgrade code questions
Next: pgsql: Add PGFILEDESC description to Makefiles for all /contrib
From: Heikki Linnakangas on 13 May 2010 02:33
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
> anymore.
>
> On the otherhand, pg_terminate_backend() just terminates a backend. So
> triggering failover is overkill.
>
> 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?

--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com

--
Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

From: Tatsuo Ishii on 13 May 2010 20:20
> > 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 memory area
indicating it rceived SIGTERM before forwarding the signal to
backends.

Backend check the flag and if it's not set, it knows that the signal
has been sent by pg_terminate_backend(), not postmaster.

What about new error code:

#define ERRCODE_BACKEND_STOP_REQUEST MAKE_SQLSTATE('5','7', 'P','0','4')
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Japanese: http://www.sraoss.co.jp

--
Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

From: Robert Haas on 14 May 2010 08:06
On Thu, May 13, 2010 at 8:20 PM, Tatsuo Ishii <ishii(a)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
>> 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 knows that the signal
> has been sent by pg_terminate_backend(), not postmaster.

Or it could also be sent by some other user process, like the user
running "kill" from the shell.

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

--
Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

From: Tatsuo Ishii on 15 May 2010 09:06
> >> 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 knows that the signal
> > has been sent by pg_terminate_backend(), not postmaster.
>
> Or it could also be sent by some other user process, like the user
> running "kill" from the shell.

No problem (at least for pgpool-II).

If the flag is not set, postgres returns the same code as the one
killed by pg_terminate_backend(). The point is, backend is killed by
postmaster or not. Because if backend was killed by postmaster,
pgpool-II should not expect the PostgreSQL server is usable since
postmaster decided to shutdown.
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Japanese: http://www.sraoss.co.jp

--
Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

 | 
Pages: 1
Prev: pg_upgrade code questions
Next: pgsql: Add PGFILEDESC description to Makefiles for all /contrib