Re: Add errdetail() with PID and UID about source of termination signal - Mailing list pgsql-hackers

From Andrew Dunstan
Subject Re: Add errdetail() with PID and UID about source of termination signal
Date
Msg-id CAD5tBcKf0mjcSpVDu4BVFe3qNMG5bPqpUETzEodo8Gduo1DZ1w@mail.gmail.com
Whole thread
In response to Re: Add errdetail() with PID and UID about source of termination signal  (Jakub Wartak <jakub.wartak@enterprisedb.com>)
List pgsql-hackers


On Thu, Apr 23, 2026 at 6:20 AM Jakub Wartak <jakub.wartak@enterprisedb.com> wrote:
On Thu, Apr 23, 2026 at 11:28 AM Chao Li <li.evan.chao@gmail.com> wrote:

Hi Chao

>
> I just got a suspicion about this feature. The repro is very simple: let a normal user connect to the server, then run pg_ctl stop, and from psql you get:
> ```
> evantest=> select 1;
> FATAL:  terminating connection due to administrator command
> DETAIL:  Signal sent by PID 17523, UID 501.
> server closed the connection unexpectedly
>         This probably means the server terminated abnormally
>         before or while processing the request.
> The connection to the server was lost. Attempting reset: Failed.
> The connection to the server was lost. Attempting reset: Failed.
> !?>
> ```
>
> Do we really need to show the DETAIL message with the PID and UID to an ordinary client? Is there any concern about leaking the UID in a shared production deployment?
>
> If this is confirmed an issue, I made a simple fix by using errdetail_log() to only emit the detail message to server log. Please the attached diff file.

+1, I think logging just to file is even better than sending it to the
client(s) and it also solves the potential security risk (if any).


I agree, I have pushed the patch.

cheers

andrew 

pgsql-hackers by date:

Previous
From: Henson Choi
Date:
Subject: Re: Row pattern recognition
Next
From: Robert Haas
Date:
Subject: Re: Why clearing the VM doesn't require registering vm buffer in wal record