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
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 |