Re: proposal: psql: psql variable BACKEND_PID

From: Andrew Dunstan <andrew(at)dunslane(dot)net>
To: Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>, Jelte Fennema <me(at)jeltef(dot)nl>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Andres Freund <andres(at)anarazel(dot)de>, Peter Eisentraut <peter(dot)eisentraut(at)enterprisedb(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: proposal: psql: psql variable BACKEND_PID
Date: 2023-03-18 15:24:09
Message-ID: 7877cb6f-073b-f7b2-9173-dfe740cd9047@dunslane.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers


On 2023-02-16 Th 23:04, Pavel Stehule wrote:
>
>
> čt 16. 2. 2023 v 12:49 odesílatel Jelte Fennema <me(at)jeltef(dot)nl> napsal:
>
> On Thu, 16 Feb 2023 at 12:44, Pavel Stehule
> <pavel(dot)stehule(at)gmail(dot)com> wrote:
> > To find and use pg_backend_pid is not rocket science. But use
> :BACKEND_PID is simpler.
>
> I wanted to call out that if there's a connection pooler (e.g.
> PgBouncer) in the middle, then BACKEND_PID (and %p) are incorrect, but
> pg_backend_pid() would work for the query. This might be an edge case,
> but if BACKEND_PID is added it might be worth listing this edge case
> in the docs somewhere.
>
>
> good note
>
>

This patch is marked RFC, but given the comments upthread from Tom,
Andres and Peter, I think it should actually be Rejected.

cheers

andrew

--
Andrew Dunstan
EDB:https://www.enterprisedb.com

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Pavel Stehule 2023-03-18 16:57:32 Re: proposal: psql: psql variable BACKEND_PID
Previous Message Tomas Vondra 2023-03-18 15:19:53 Re: logical decoding and replication of sequences, take 2