| From: | Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | pgsql-hackers(at)lists(dot)postgresql(dot)org |
| Subject: | Re: Why aren't we using strsignal(3) ? |
| Date: | 2018-12-17 17:03:29 |
| Message-ID: | 20181217170329.njoowigcqaqevulp@alvherre.pgsql |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On 2018-Dec-17, Tom Lane wrote:
> But it looks like
> we could drop the sys_siglist support for an undetectably small penalty:
> even if, somewhere, there's a platform that has sys_siglist[] but not
> strsignal(), it'd just mean that you get only a signal number and have
> to look up its meaning.
>
> While a dozen lines in pgstrsignal.c certainly are not worth worrying
> over, getting rid of the configure test for sys_siglist[] would save
> some cycles on every build. So I'm tempted to drop it. Thoughts?
+1 for nuking it. configure times grow larger, and there's seldom a
change to make them shorter. In this case, per your analysis, it
doesn't look like we're losing anything worthwhile.
--
Álvaro Herrera https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Petr Jelinek | 2018-12-17 17:16:37 | Re: Minimal logical decoding on standbys |
| Previous Message | Abhijit Menon-Sen | 2018-12-17 16:59:28 | Re: Why aren't we using strsignal(3) ? |