From: Tom Lane <tgl@sss.pgh.pa.us>
To: Jelte Fennema <Jelte.Fennema@microsoft.com>
cc: Andres Freund <andres@anarazel.de>,
        Fujii Masao <masao.fujii@oss.nttdata.com>,
        Zhihong Yu <zyu@yugabyte.com>,
        "pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>
Subject: Re: [EXTERNAL] Re: PQcancel does not use tcp_user_timeout,
 connect_timeout and keepalive settings
In-reply-to: <2918809.1641947968@sss.pgh.pa.us>
References: 
 <AM5PR83MB017870DE81FC84D5E21E9D1EF7AA9@AM5PR83MB0178.EURPRD83.prod.outlook.com>
 <CALNJ-vSbOyVm9nk3y1UwA3e+M8atwJtTg_3ugRfC5W+TyAbMZQ@mail.gmail.com>
 <AM5PR83MB01781C8E94AEC8073B646872F7B09@AM5PR83MB0178.EURPRD83.prod.outlook.com>
 <AM5PR83MB0178586E6B079DF8E7F0D855F7B09@AM5PR83MB0178.EURPRD83.prod.outlook.com>
 <b79defeb-e938-2840-8adf-fa0af08e2c2b@oss.nttdata.com>
 <1473763.1636578406@sss.pgh.pa.us>
 <HE1PR83MB0186173FC957C2554D0A31B6F7939@HE1PR83MB0186.EURPRD83.prod.outlook.com>
 <AM5PR83MB0178DCFFC1BE77C4C390DA89F7439@AM5PR83MB0178.EURPRD83.prod.outlook.com>
 <20220105184225.5xfekapzg5o3uq7a@alap3.anarazel.de>
 <794237.1641408889@sss.pgh.pa.us>
 <AM5PR83MB01782D9A7D607B0419B3CB47F74C9@AM5PR83MB0178.EURPRD83.prod.outlook.com>
 <2912315.1641943641@sss.pgh.pa.us> <2918809.1641947968@sss.pgh.pa.us>
Comments: In-reply-to Tom Lane <tgl@sss.pgh.pa.us>
	message dated "Tue, 11 Jan 2022 19:39:28 -0500"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <2937813.1641960929.1@sss.pgh.pa.us>
Date: Tue, 11 Jan 2022 23:15:29 -0500
Message-ID: <2937814.1641960929@sss.pgh.pa.us>
Archived-At: 
 <https://www.postgresql.org/message-id/2937814.1641960929%40sss.pgh.pa.us>
Precedence: bulk

... btw, speaking of signal-safe functions: I am dismayed to
notice that strerror (and strerror_r) are *not* in POSIX's
list of async-signal-safe functions.  This is really quite
unsurprising, considering that they are chartered to return
locale-dependent strings.  Unless the data has already been
collected in the current process, that'd imply reading something
from the locale definition files, allocating memory to hold it,
etc.

So I'm now thinking this bit in PQcancel is completely unsafe:

        strncat(errbuf, SOCK_STRERROR(SOCK_ERRNO, sebuf, sizeof(sebuf)),
                maxlen);

Seems we have to give up on providing any details beyond the
name of the function that failed.

			regards, tom lane