From: | Tatsuo Ishii <ishii(at)postgresql(dot)org> |
---|---|
To: | robertmhaas(at)gmail(dot)com |
Cc: | ishii(at)postgresql(dot)org, heikki(dot)linnakangas(at)enterprisedb(dot)com, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: How to know killed by pg_terminate_backend |
Date: | 2010-05-15 13:06:46 |
Message-ID: | 20100515.220646.41634217.t-ishii@sraoss.co.jp |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
> >> 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
From | Date | Subject | |
---|---|---|---|
Next Message | Simon Riggs | 2010-05-15 13:16:45 | Re: HS/SR Assert server crash |
Previous Message | Kevin Grittner | 2010-05-15 11:09:45 | Re: Row-level Locks & SERIALIZABLE transactions, postgres vs. Oracle |