| From: | Andres Freund <andres(at)anarazel(dot)de> |
|---|---|
| To: | pgsql-hackers(at)postgresql(dot)org |
| Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Joachim Wieland <joe(at)mcknight(dot)de>, Simon Riggs <simon(at)2ndquadrant(dot)com>, Kris Jurka <books(at)ejurka(dot)com> |
| Subject: | Re: Hot Standy introduced problem with query cancel behavior |
| Date: | 2009-12-29 16:04:13 |
| Message-ID: | 200912291704.14135.andres@anarazel.de |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Tuesday 29 December 2009 16:22:54 Tom Lane wrote:
> Joachim Wieland <joe(at)mcknight(dot)de> writes:
> > If we use the same signal for both cases, the receiving backend cannot
> > tell what the intention of the sending backend was. That's why I
> > proposed to make SIGINT similar to SIGUSR1 where we write a reason to
> > a shared memory structure first and then send the signal (see
> > http://archives.postgresql.org/pgsql-hackers/2009-12/msg02067.php from
> > a few days ago).
> This seems like a fairly bad idea. One of the intended use-cases is to
> be able to manually "kill -INT" a misbehaving backend. Assuming that
> there will be valid info about the signal in shared memory will break
> that.
Well. That already is the case now. MyProc->recoveryConflictMode is checked to
recognize what kind of conflict is being resolved...
Andres
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2009-12-29 16:13:03 | Re: Hot Standy introduced problem with query cancel behavior |
| Previous Message | Kevin Grittner | 2009-12-29 16:00:52 | Re: Serializable implementation |