Re: Add errdetail() with PID and UID about source of termination signal

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Andrew Dunstan <andrew(at)dunslane(dot)net>
Cc: Jakub Wartak <jakub(dot)wartak(at)enterprisedb(dot)com>, Chao Li <li(dot)evan(dot)chao(at)gmail(dot)com>, Andres Freund <andres(at)anarazel(dot)de>, Jim Jones <jim(dot)jones(at)uni-muenster(dot)de>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Add errdetail() with PID and UID about source of termination signal
Date: 2026-04-15 16:04:12
Message-ID: 2007157.1776269052@sss.pgh.pa.us
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Andrew Dunstan <andrew(at)dunslane(dot)net> writes:
> On 2026-04-15 We 10:37 AM, Tom Lane wrote:
>> The OpenBSD members of the buildfarm don't seem to like this.

> Ugh.
> I'm will take a look later today.

I reproduced it locally on OpenBSD 7.7. HAVE_SA_SIGINFO is defined,
and the code to grab the pid/uid out of siginfo_t is definitely
getting compiled. As best I can tell, the kernel is simply passing
zero for info->si_pid and si_uid. This does not match up with the
info available on the net, so I'm not sure what the issue is.

Some googling suggested that on some platforms si_pid will be zero
if the process signaled itself, but I can eliminate that theory:
it's still zero if I do the pg_terminate_backend() from another
session.

As a short-term fix, we could just go back to allowing the regex to
consider the match optional.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Jacob Champion 2026-04-15 16:23:14 Re: Add errdetail() with PID and UID about source of termination signal
Previous Message Mihail Nikalayeu 2026-04-15 15:54:12 Re: Adding REPACK [concurrently]