| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Andres Freund <andres(at)anarazel(dot)de> |
| Cc: | Heikki Linnakangas <hlinnaka(at)iki(dot)fi>, Asim R P <apraveen(at)pivotal(dot)io>, Jimmy Yih <jyih(at)pivotal(dot)io>, PostgreSQL mailing lists <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: [HACKERS] possible self-deadlock window after bad ProcessStartupPacket |
| Date: | 2018-07-19 19:49:35 |
| Message-ID: | 23058.1532029775@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Andres Freund <andres(at)anarazel(dot)de> writes:
> On 2018-07-19 11:57:25 +0300, Heikki Linnakangas wrote:
>> The regular backend's quickdie() function is more tricky. It should also
>> call _exit(2) rather than exit(2). But it also tries to ereport a WARNING,
>> and that is quite useful.
There's already an on_exit_reset in there; why do we need more than that?
> Is that actually true? Clients like libpq create the same error message
> (which has its own issues, because it'll sometimes mis-interpret
> things). The message doesn't actually have useful content, no?
Yes, it does: it lets users tell the difference between exit due to a
SIGQUIT and a crash of their own backend.
Admittedly, if we crash trying to send the message, then we're not
better off. But since that happens only very rarely, I do not think
it's a reasonable tradeoff to never send it at all.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Andres Freund | 2018-07-19 19:51:01 | Re: Possible performance regression in version 10.1 with pgbench read-write tests. |
| Previous Message | Andres Freund | 2018-07-19 19:43:42 | Re: [HACKERS] logical decoding of two-phase transactions |