Re: Add errdetail() with PID and UID about source of termination signal
| От | Andrew Dunstan |
|---|---|
| Тема | Re: Add errdetail() with PID and UID about source of termination signal |
| Дата | |
| Msg-id | c7ec08db-e5e0-42bf-acaa-4cc09d9649f6@dunslane.net обсуждение |
| Ответ на | Re: Add errdetail() with PID and UID about source of termination signal (Tom Lane <tgl@sss.pgh.pa.us>) |
| Ответы |
Re: Add errdetail() with PID and UID about source of termination signal
|
| Список | pgsql-hackers |
On 2026-04-15 We 12:04 PM, Tom Lane wrote: > Andrew Dunstan <andrew@dunslane.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. > > Ok, so we can get the buildfarm green I'll go and do that. But I think we should have an open item to tighten the test. cheers andrew -- Andrew Dunstan EDB: https://www.enterprisedb.com
В списке pgsql-hackers по дате отправления: