so 18. 3. 2023 v 16:24 odesílatel Andrew Dunstan
napsal:
>
> On 2023-02-16 Th 23:04, Pavel Stehule wrote:
>
>
>
> čt 16. 2. 2023 v 12:49 odesílatel Jelte Fennema napsal:
>
>> On Thu, 16 Feb 2023 at 12:44, Pavel Stehule
>> wrote:
>> > To find and use pg_backend_pid is not rocket science. But use
On 2023-02-16 Th 23:04, Pavel Stehule wrote:
čt 16. 2. 2023 v 12:49 odesílatel Jelte Fennema napsal:
On Thu, 16 Feb 2023 at 12:44, Pavel Stehule
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
čt 16. 2. 2023 v 12:49 odesílatel Jelte Fennema napsal:
> On Thu, 16 Feb 2023 at 12:44, Pavel Stehule
> 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 middl
On Thu, 16 Feb 2023 at 12:44, Pavel Stehule 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() wou
On 13.02.23 18:33, Pavel Stehule wrote:
In every real use case you can use pg_backend_pid(), but you need to
write a complete name without tab complete, and you need to know so this
function is available.
BACKEND_PID is supported by tab complete, and it is displayed in \set
list and \? varia
po 13. 2. 2023 v 18:52 odesílatel Tom Lane napsal:
> Andres Freund 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 mo
Hi,
On 2023-02-13 12:52:23 -0500, Tom Lane wrote:
> Andres Freund writes:
> > 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_sta
Andres Freund 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
Hi,
On 2023-02-13 18:06:23 +0100, Peter Eisentraut wrote:
> On 09.02.23 10:11, Pavel Stehule wrote:
> > first and main (for me) - I can use psql variables tab complete - just
> > :B - it is significantly faster
> > second - I can see all connection related information by \set
> > third - there is
po 13. 2. 2023 v 18:06 odesílatel Peter Eisentraut <
peter.eisentr...@enterprisedb.com> napsal:
> On 09.02.23 10:11, Pavel Stehule wrote:
> > first and main (for me) - I can use psql variables tab complete - just
> > :B - it is significantly faster
> > second - I can see all connection related inf
On 09.02.23 10:11, Pavel Stehule wrote:
first and main (for me) - I can use psql variables tab complete - just
:B - it is significantly faster
second - I can see all connection related information by \set
third - there is not hook on reconnect in psql - so if you implement
BACKEND_PID by self,
On 2023-02-04 15:35:58 -0500, Corey Huinker wrote:
> This effectively makes the %p prompt (which I use in the example above) the
> same as %:BACKEND_PID: and we may want to note that in the documentation.
I don't really see much of a point in noting this in the doc. I don't know in
what situation
Hi,
On 2023-02-09 10:11:21 +0100, Pavel Stehule wrote:
> first and main (for me) - I can use psql variables tab complete - just
> :B - it is significantly faster
> second - I can see all connection related information by \set
> third - there is not hook on reconnect in psql - so if you implement
>
čt 9. 2. 2023 v 9:57 odesílatel Peter Eisentraut <
peter.eisentr...@enterprisedb.com> napsal:
> On 03.02.23 11:41, Pavel Stehule wrote:
> > We can simply allow an access to backend process id thru psql variable.
> > I propose the name "BACKEND_PID". The advantages of usage are simple
> > accessibi
On 03.02.23 11:41, Pavel Stehule wrote:
We can simply allow an access to backend process id thru psql variable.
I propose the name "BACKEND_PID". The advantages of usage are simple
accessibility by command \set, and less typing then using function
pg_backend_pid, because psql variables are supp
po 6. 2. 2023 v 13:03 odesílatel Daniel Verite
napsal:
> I wrote:
>
> > > In the varlistentry, I suggest we add "This variable is unset when the
> > > connection is lost." after "but can be changed or unset.
> >
> > Personally I'd much rather have BACKEND_PID set to 0 rather than being
>
I wrote:
> > In the varlistentry, I suggest we add "This variable is unset when the
> > connection is lost." after "but can be changed or unset.
>
> Personally I'd much rather have BACKEND_PID set to 0 rather than being unset
> when not connected. For one thing it allows safely using \if
Corey Huinker wrote:
> Manually testing confirms that it works, at least for the connected state. I
> don't actually know how get psql to invoke DISCONNECT, so I killed the dev
> server and can confirm
Maybe something like this could be used, with no external action:
postgres=# \echo :
po 6. 2. 2023 v 0:35 odesílatel Corey Huinker
napsal:
> The following review has been posted through the commitfest application:
> make installcheck-world: tested, passed
> Implements feature: tested, passed
> Spec compliant: tested, passed
> Documentation:tested, pas
po 6. 2. 2023 v 0:25 odesílatel Corey Huinker
napsal:
>
>>>
>>> Clearly, it is hard to write a regression test for an externally
>>> volatile value. `SELECT sign(:BACKEND_PID)` would technically do the job,
>>> if we're striving for completeness.
>>>
>>
>> I did simple test - :BACKEND_PID should
The following review has been posted through the commitfest application:
make installcheck-world: tested, passed
Implements feature: tested, passed
Spec compliant: tested, passed
Documentation:tested, passed
A small but helpful feature.
The new status of this patch is
>
>
>>
>> Clearly, it is hard to write a regression test for an externally volatile
>> value. `SELECT sign(:BACKEND_PID)` would technically do the job, if we're
>> striving for completeness.
>>
>
> I did simple test - :BACKEND_PID should be equal pg_backend_pid()
>
>
Even better.
>
>>
>> Do we w
Hi
so 4. 2. 2023 v 21:36 odesílatel Corey Huinker
napsal:
> with doc and unsetting variable
>>
>> Regards
>>
>> Pavel
>>
>>
> Patch applies.
>
> Manually testing confirms that it works, at least for the connected state.
> I don't actually know how get psql to invoke DISCONNECT, so I killed the
>
> with doc and unsetting variable
>
> Regards
>
> Pavel
>
>
Patch applies.
Manually testing confirms that it works, at least for the connected state.
I don't actually know how get psql to invoke DISCONNECT, so I killed the
dev server and can confirm
[81:14:57:01 EST] corey=# \echo :BACKEND_
Hi
pá 3. 2. 2023 v 20:27 odesílatel Corey Huinker
napsal:
>
>
> On Fri, Feb 3, 2023 at 5:42 AM Pavel Stehule
> wrote:
>
>> Hi
>>
>> We can simply allow an access to backend process id thru psql variable. I
>> propose the name "BACKEND_PID". The advantages of usage are simple
>> accessibility b
On Fri, Feb 3, 2023 at 5:42 AM Pavel Stehule
wrote:
> Hi
>
> We can simply allow an access to backend process id thru psql variable. I
> propose the name "BACKEND_PID". The advantages of usage are simple
> accessibility by command \set, and less typing then using function
> pg_backend_pid, becaus
26 matches
Mail list logo
