Re: proposal: psql: psql variable BACKEND_PID
От | Tom Lane |
---|---|
Тема | Re: proposal: psql: psql variable BACKEND_PID |
Дата | |
Msg-id | 1267548.1676310743@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: proposal: psql: psql variable BACKEND_PID (Andres Freund <andres@anarazel.de>) |
Ответы |
Re: proposal: psql: psql variable BACKEND_PID
Re: proposal: psql: psql variable BACKEND_PID |
Список | pgsql-hackers |
Andres Freund <andres@anarazel.de> writes: > On 2023-02-13 18:06:23 +0100, Peter Eisentraut wrote: >> But what do you need the backend PID for in the first place? > For me it's using gdb, pidstat, strace, perf, ... > But for those %p in the PROMPTs is more useful. Indeed, because ... > E.g. I fire of a query, it's slower than I'd like, I want to attach perf. Of > course I can establish a separate connection, query pg_stat_activity there, > and then perf. But that requires manually filtering pg_stat_activity to find > the query. ... in this case, the problem is that the session is tied up doing the slow query. You can't run "select pg_backend_pid()", but you can't extract a psql variable value either. If you had the foresight to set up a PROMPT, or to collect the PID earlier, you're good. But I'm still not seeing where a psql variable makes that easier. I don't buy Pavel's argument that adding Yet Another built-in variable adds ease of use. I think what it mostly adds is clutter. I realize that "psql --help=variables | wc" is already 160+ lines, but that doesn't mean that making it longer and longer is a net improvement. regards, tom lane
В списке pgsql-hackers по дате отправления: