On Fri, Apr 11, 2025 at 3:47 AM Robert Haas wrote:
> I'd probably write the increments as ++ rather than += 1 but I'm not
> sure if everyone would agree.
I'm a fan of ++ as well, so I agree.
Thanks
Richard
u want to see everything, you'll now need to join
the two views -- and there's no guarantee that you'll get a consistent
read across both of them, so the join might do weird things unless
you're very careful.
If we do decide to keep it separate, I think we should consider
omitting
On Mon, Mar 03, 2025 at 11:35:15AM -0600, Sami Imseih wrote:
> Thanks for the update. This LGTM! and I will mark as RFC.
Yes, agreed that there is no specific need to be precise about the
attributes that can become inconsistent, as this would also depend on
the addition of more states, or event mo
== STATE_STARTING`. I plan to mark this patchset as Withdrawn for now.
Okay, fine by me. I had the impression that it would have been
possible to salvage some of the wait event states, but at least the
starting state showing up in pg_stat_activity will be able to provide
some information, so it&#
On Thu, Mar 13, 2025 at 10:56 AM Andres Freund wrote:
> > Given the choice between a usually-working PAM module with known
> > architectural flaws, and not having PAM at all, I think many users
> > would rather continue using what's working for them.
>
> authentication_timeout currently doesn't re
On 2025-03-13 10:29:49 -0700, Jacob Champion wrote:
> On Thu, Mar 13, 2025 at 9:56 AM Andres Freund wrote:
> > I am wondering if PAM is so fundamentally incompatible with handling
> > interrupts / a non-blocking interface that we have little choice but to
> > eventually remove it...
>
> Given the
On Thu, Mar 13, 2025 at 9:56 AM Andres Freund wrote:
> I am wondering if PAM is so fundamentally incompatible with handling
> interrupts / a non-blocking interface that we have little choice but to
> eventually remove it...
Given the choice between a usually-working PAM module with known
architec
Hi,
On 2025-03-13 09:23:10 -0700, Jacob Champion wrote:
> On Wed, Mar 12, 2025 at 3:16 PM Jacob Champion
> wrote:
> > I missed PAM_CONV, sorry. I'm worried about the sendAuthRequest()
> > being done there; it doesn't seem safe to potentially ereport(ERROR)
> > and longjmp through a PAM call stack
On Wed, Mar 12, 2025 at 3:16 PM Jacob Champion
wrote:
> I missed PAM_CONV, sorry. I'm worried about the sendAuthRequest()
> being done there; it doesn't seem safe to potentially ereport(ERROR)
> and longjmp through a PAM call stack? But I'll switch those over to
> something safe or else drop that
nk it's better suited for
pgstatfuncs.h (though existing function - pg_stat_get_progress_info - does
the same)
#define PG_STAT_GET_SESSION_COLS 9
7. Some information is currently scattered between pg_stat_session and
pg_stat_activity, making joins necessary. However, pg_stat_activity
contains
On Fri, Mar 7, 2025 at 10:28 AM Jacob Champion
wrote:
> > I think some of the wrapped calls into library code might actually call back
> > into our code (to receive/send data), and our code then will use wait events
> > around lower level operations done as part of that.
>
> That would be a proble
does
the same)
#define PG_STAT_GET_SESSION_COLS 9
7. Some information is currently scattered between pg_stat_session and
pg_stat_activity, making joins necessary. However, pg_stat_activity
contains two types of columns: Those being immutable during a session
(e.g., client_addr, application_name, usename) an
On Fri, Mar 7, 2025 at 9:25 AM Andres Freund wrote:
> I should have clarified - there are a few that I think are ok, basically the
> places where we wrap syscalls, e.g. around the sendto, select and recvfrom in
> PerformRadiusTransaction().
Okay.
> OTOH that code is effectively completely broken
Hi,
On 2025-03-07 09:03:18 -0800, Jacob Champion wrote:
> On Fri, Mar 7, 2025 at 8:38 AM Andres Freund wrote:
> > FWIW, I continue to think that this is a misuse of wait events. We shouldn't
> > use them as a poor man's general purpose tracing framework.
>
> Well, okay. That's frustrating.
I sho
On Fri, Mar 7, 2025 at 8:38 AM Andres Freund wrote:
> FWIW, I continue to think that this is a misuse of wait events. We shouldn't
> use them as a poor man's general purpose tracing framework.
Well, okay. That's frustrating.
If I return to the original design, but replace all of the high-level
w
Hi,
On 2025-03-06 15:39:44 -0800, Jacob Champion wrote:
> I've reattached the wait event patches, to get the cfbot back to where it was.
FWIW, I continue to think that this is a misuse of wait events. We shouldn't
use them as a poor man's general purpose tracing framework.
Greetings,
Andres Fre
ELECT state FROM pg_stat_activity WHERE pid = ;
[14:19:55.228](0.004s) # pump_until: process terminated
unexpectedly when searching for "(?^:(^|\n)background_psql:
QUERY_SEPARATOR 34:\r?\n)" with stream: ""
process ended prematurely at
/home/jacob/src/postgres/src/test/per
On Thu, Mar 6, 2025 at 3:15 PM Michael Paquier wrote:
> I have applied the simplest patch for now, to silence the failures in
> the CI, and included your suggestion to add a check on the
> backend_type for the extra safety it offers.
Thanks! Initial CI run looks green, so that's a good start.
I'
On Thu, Mar 06, 2025 at 02:25:07PM -0800, Jacob Champion wrote:
> On Wed, Mar 5, 2025 at 8:08 PM Michael Paquier wrote:
>> + WHERE state = 'starting' and wait_event = 'init-pre-auth';});
>
> Did you have thoughts on expanding the check to backend_type [1]?
>
>> + # Give up. The output of the l
he $psql connection handle for server interaction.
my $conn = $node->background_psql('postgres', wait => 0);
-# Wait for the connection to show up.
-my $pid;
-while (1)
-{
- $pid = $psql->query(
- "SELECT pid FROM pg_stat_activity WHERE state = 'starting';"
Hi,
On 2025-03-05 16:19:04 -0800, Jacob Champion wrote:
> On Wed, Mar 5, 2025 at 9:28 AM Andres Freund wrote:
> > Unrelated to the change in this patch, but tests really shouldn't use
> > while(1)
> > loops without a termination condition. If something is wrong, the test will
> > hang indefinite
On Wed, Mar 5, 2025 at 9:28 AM Andres Freund wrote:
> Unrelated to the change in this patch, but tests really shouldn't use while(1)
> loops without a termination condition. If something is wrong, the test will
> hang indefinitely, instead of timing out. On the buildfarm that can take out
> an an
$node->background_psql('postgres', wait => 0);
>
> -# Wait for the connection to show up.
> +# Wait for the connection to show up in pg_stat_activity, with the wait_event
> +# of the injection point.
> my $pid;
> while (1)
> {
> $pid =
On Wed, Mar 5, 2025 at 5:47 AM Jacob Champion
wrote:
>
> So while we're at it, should we add a
> `backend_type = 'client backend'` filter to stop that from flaking in
> the future? That would further align this query with the
> wait_for_event() implementation.
More concretely: here's a squashable
On Tue, Mar 4, 2025 at 8:45 PM Michael Paquier wrote:
> What this is telling us is that we should change the query scanning
> pg_stat_activity for a PID of a backend in 'starting' state so as we
> also check the wait_event init-pre-auth, as this is reported when
> using
On Tue, Mar 4, 2025 at 4:10 PM Andres Freund wrote:
> This seems to trigger a bunch of CI failures, e.g.:
>
> https://cirrus-ci.com/task/5350341408980992
> https://cirrus-ci.com/task/5537391798124544
> https://cirrus-ci.com/task/4657439905153024
Hm. All Windows.
> https://api.cirrus-ci.com/v1/ar
this is telling us is that we should change the query scanning
pg_stat_activity for a PID of a backend in 'starting' state so as we
also check the wait_event init-pre-auth, as this is reported when
using injection point waits. The attached should be enough to ta
On Tue, Mar 4, 2025 at 4:26 PM Jacob Champion
wrote:
> But attaching to that injection point succeeded above, for us to have
> gotten to this point... Does that error message indicate that the
> point itself doesn't exist, or that nothing is currently waiting?
Looks like the latter. With the foll
5153024
https://api.cirrus-ci.com/v1/artifact/task/5350341408980992/testrun/build/testrun/authentication/007_pre_auth/log/regress_log_007_pre_auth
[17:47:59.698](0.000s) ok 1 - authenticating connections are recorded in
pg_stat_activity
[17:47:59.698](0.000s) # issuing query 5 via background
On Tue, Mar 4, 2025 at 12:51 AM Michael Paquier wrote:
>
> On Mon, Mar 03, 2025 at 02:23:51PM +0900, Michael Paquier wrote:
> > This has always been set last and it's still the case in the patch, so
> > let's just remove that.
>
> This first one has been now applied as c76db55c9085.
Thanks!
> At
On Mon, Mar 03, 2025 at 02:23:51PM +0900, Michael Paquier wrote:
> This has always been set last and it's still the case in the patch, so
> let's just remove that.
This first one has been now applied as c76db55c9085. Attached is the
rest to add the wait events (still need to have a closer look at
Thanks for the update. This LGTM! and I will mark as RFC.
--
Sami
rc/backend/catalog/system_views.sql b/src/backend/catalog/system_views.sql
index a4d2cfdcaf..0f191c9b8e 100644
--- a/src/backend/catalog/system_views.sql
+++ b/src/backend/catalog/system_views.sql
@@ -895,6 +895,19 @@ CREATE VIEW pg_stat_activity AS
LEFT JOIN pg_database AS D ON (S.dat
ion open for a good amount of that, and some
authentication methods call out to external systems, having an early
pg_stat_activity entry helps DBAs debug when things go badly wrong.
2) pgstat_bestart_security() reports the SSL/GSS status of the
connection. Some backends don't call th
iscrepancies may exist between the view's columns.
Best regards,
Alex FriedmanFrom 58de88469f6201ae698ee34debcdec028526a72a Mon Sep 17 00:00:00 2001
From: Alex Friedman
Date: Wed, 26 Feb 2025 19:59:59 +0200
Subject: [PATCH v3] Clarify possibility of ephemeral discrepancies between
state
s_attach('init-pre-auth', 'wait')");
-+
-+ # From this point on, all new connections will hang during startup, just
-+ # before authentication. Use the $psql connection handle for server
-+ # interaction.
-+ my $conn = $node->background_psql(
> It's also worth noting that pg_locks already has a full paragraph explaining
> inconsistencies, so in my opinion it's worth it at least mentioning something
> similar here for pg_stat_activity.
yes, that is a different consistency from the one I was referring to with
regard
eady has a full paragraph explaining
inconsistencies, so in my opinion it's worth it at least mentioning something
similar here for pg_stat_activity.
Best regards,
Alex FriedmanFrom fbbfc623e16ed97176c0ccf0ebc534d118e9f252 Mon Sep 17 00:00:00 2001
From: Alex Friedman
Date: Wed, 26 Feb
ephemeral discrepancies
across all these fields.
Another common pattern is joining pg_stat_activity and pg_locks,
and that will have the same problem. Of course, these are different
views being joined, so maybe there isn't an expectation of 100%
accuracy, but worth calling this out as well.
If
Hi,
This small doc change patch is following up on a past discussion about
discrepancies between state and wait_event in pg_stat_activity:
https://www.postgresql.org/message-id/flat/ab1c0a7d-e789-5ef5-1180-42708ac6fe2d%40postgrespro.ru
As this kind of question is raised by PG users from
On Saturday, February 15, 2025, Rajesh Kumar
wrote:
> If I see a sudden connection spike (say once in 2 months). What are the
> steps I need to follow as a dba?
>
> Check idle and kill? Check of stat activity for active queries? How do I
> ensure how much time is long running query? Blocking quer
If I see a sudden connection spike (say once in 2 months). What are the
steps I need to follow as a dba?
Check idle and kill? Check of stat activity for active queries? How do I
ensure how much time is long running query? Blocking queries? How much of
blocking time is considered to be dangerous? L
On Thu, Feb 13, 2025 at 4:03 PM Michael Paquier wrote:
> > If a CA is issuing Subject data that is somehow dangerous to the
> > operation of the server, I think that's a security problem in and of
> > itself: there are clientcert HBA modes that don't validate the
> > Subject, but they're still goi
On Thu, Feb 13, 2025 at 09:53:52AM -0800, Jacob Champion wrote:
> I guess I'm going to zero in on your definition of "may know nothing
> about". If that is true, something is very wrong IMO.
>
> My understanding of the backend code was that port->peer is only set
> after OpenSSL has verified that
On Tue, Feb 11, 2025 at 11:23 PM Michael Paquier wrote:
> +be_tls_get_peer_subject_name(MyProcPort, lsslstatus.ssl_client_dn,
> NAMEDATALEN);
> +be_tls_get_peer_serial(MyProcPort, lsslstatus.ssl_client_serial,
> NAMEDATALEN);
> +be_tls_get_peer_issuer_name(MyProcPort, lss
On Mon, Feb 10, 2025 at 11:05:32AM -0800, Jacob Champion wrote:
> Bad regex escaping on my part; fixed in v8. Thanks for the report!
>
> While debugging, I also noticed that a poorly timed autovacuum could
> also show up in my new pg_stat_activity query, so I've increased the
&g
While debugging, I also noticed that a poorly timed autovacuum could
also show up in my new pg_stat_activity query, so I've increased the
specificity.
> Do we _want_ nine separate flavors of WAIT_EVENT_LDAP_UNBIND? I
> figured it was enough to know that you were stuck unbinding.
v
osed to enforce that, but I see that it's not for some
reason. That's concerning. I'll investigate, thanks for pointing it
out.
> With this patch, the information that we get to be able to debug a
> backend entry in pg_stat_activity is st_clientaddr and
> remote_hostname.
d once authentication is completed, even
perhaps have a static rule to engrave this policy in stone.
With this patch, the information that we get to be able to debug a
backend entry in pg_stat_activity is st_clientaddr and
remote_hostname. If we have a backend stuck in a wait event for the
"A
sted in the pg_stat_activity view but
> renaming to something like 'pg_stat_backend' seems reasonable to me.
For now I kept the "pg_stat_session" naming because I don't know how
desirable it is to collect the
resource statistics in this view given that a plenty of other pg
On Fri, Nov 8, 2024 at 4:23 PM Jacob Champion
wrote:
> While I work on breaking pgstat_bestart() apart, here is a v6 which
> pushes down the "coarse" wait events. No changes to 0001 yet.
v7 rewrites 0001 by splitting pgstat_bestart() into three phases.
(0002-3 are unchanged.)
1. pgstat_bestart_i
On Thu, Nov 7, 2024 at 4:38 PM Jacob Champion
wrote:
> Oh... I think that alone is enough to change my mind; I neglected the
> effects of that little pgstat_report_appname() stinger...
(Note that application_name is not yet set at the site of the first
call, so I think the set-unset-set can't hap
On Thu, Nov 7, 2024 at 2:56 PM Andres Freund wrote:
> It does actually make things harder - what if somebody added a
> pgstat_report_activity() somewhere between the call? It would suddenly get
> lost after the second "initialization". Actually, the proposed patch already
> has weird, externally
ns that set up the user,
database, SSL, GSS information separately.
> > If you increase the iteration count for whatever secret
> > "hashing" method to be very high, it's not a wait, it's just CPU
> > use.
>
> I don't yet understand why this is
quot;hashing" method to be very high, it's not a wait, it's just CPU
> use.
I don't yet understand why this is a useful distinction to make. I
understand that they are different, but what are the bad consequences
if pg_stat_activity records a CPU busy wait in the same way it re
Hi,
On 2024-11-07 12:11:46 -0800, Jacob Champion wrote:
> On Thu, Nov 7, 2024 at 11:41 AM Andres Freund wrote:
> > I think the patch should not be merged as-is. It's just too ugly and
> > fragile.
>
> Understood; I'm trying to find a way forward, and I'm pointing out
> that the alternatives I'v
On Thu, Nov 7, 2024 at 11:41 AM Andres Freund wrote:
> I think the patch should not be merged as-is. It's just too ugly and fragile.
Understood; I'm trying to find a way forward, and I'm pointing out
that the alternatives I've tried seem to me to be _more_ fragile.
Are there any items in this li
Hi,
On 2024-11-07 10:44:25 -0800, Jacob Champion wrote:
> On Thu, Nov 7, 2024 at 10:12 AM Andres Freund wrote:
> > I don't understand why the pgstat_bestart()/pgstat_bestart_pre_auth() split
> > makes sense. The latter is going to redo most of the work that the former
> > did. What's the point of
On Thu, Nov 7, 2024 at 10:12 AM Andres Freund wrote:
> I don't understand why the pgstat_bestart()/pgstat_bestart_pre_auth() split
> makes sense. The latter is going to redo most of the work that the former
> did. What's the point of that?
>
> Why not have a new function that initializes just the
t_bestart_pre_auth(), which reports a 'starting' state while
> waiting for backend initialization and client authentication to
> complete. Since we hold a transaction open for a good amount of that,
> and some authentication methods call out to external systems, having a
> pg_s
On Tue, Nov 5, 2024 at 9:48 PM Michael Paquier wrote:
> +PAM_ACCT_MGMT "Waiting for the local PAM service to validate the user
> account."
> +PAM_AUTHENTICATE "Waiting for the local PAM service to authenticate
> the user."
>
> Is "local" required for both? Perhaps just use "the PAM servi
On Wed, Nov 06, 2024 at 02:48:31PM +0900, Michael Paquier wrote:
> I'm OK with 0002 to add the wait parameter to BackgroundPsql and be
> able to take some actions until a manual wait_connect(). I'll go do
> this one. Also perhaps 0001 while on it but I am a bit puzzled by the
> removal of the thr
On Fri, Nov 01, 2024 at 02:47:38PM -0700, Jacob Champion wrote:
> On Sun, Sep 1, 2024 at 5:10 PM Michael Paquier wrote:
>> Could it be more transparent to use a "startup" or
>> "starting"" state instead that gets also used by pgstat_bestart() in
>> the case of the patch where !pre_auth?
>
> Done.
waiting for backend initialization and client authentication to
complete. Since we hold a transaction open for a good amount of that,
and some authentication methods call out to external systems, having a
pg_stat_activity entry helps DBAs debug when things go badly wrong.
On Tue, Feb 20, 2024 at 10:32:53PM +0100, Magnus Hagander wrote:
> In a way, that's yet another different type of values though -- it
> contains accumulated stats. So we really have 3 types -- "info" that's
> not really stats (username, etc), "current state" (query, wait events,
> state) and "accum
On Thu, Oct 03, 2024 at 10:00:00PM +0300, Alexander Lakhin wrote:
> I've managed to falsify the Assert in ExecutorRun() with the following:
> SET compute_query_id = 'off';
> SET track_activities = 'off';
>
> CALL p2(0);
>
> CALL p2(1);
Fun. This manipulates the session to force the state of the
Hello Michael,
02.10.2024 06:29, Michael Paquier wrote:
On Wed, Oct 02, 2024 at 06:00:00AM +0300, Alexander Lakhin wrote:
Fortunately, it's still pretty warm here, so I'm wearing T-shirt and my
sleeve isn't long enough for that, but if you gave me 2-3 days, I would
focus on researching this are
On Wed, Oct 02, 2024 at 06:00:00AM +0300, Alexander Lakhin wrote:
> Fortunately, it's still pretty warm here, so I'm wearing T-shirt and my
> sleeve isn't long enough for that, but if you gave me 2-3 days, I would
> focus on researching this area...
Sure, thanks. I am also spending a few days thi
Hello Michael,
02.10.2024 03:52, Michael Paquier wrote:
Alexander, I've thought about a couple of fancy cases for
ExecutorRun() but I could not break it. Perhaps you have something in
your sleeve that would also break this case?
--
Fortunately, it's still pretty warm here, so I'm wearing T-sh
On Tue, Oct 01, 2024 at 10:00:00PM +0300, Alexander Lakhin wrote:
> Hello Michael,
>
> 01.10.2024 05:07, Michael Paquier wrote:
> > On Mon, Sep 30, 2024 at 10:07:55AM +0900, Michael Paquier wrote:
> > ...
> > And done this part.
>
> If I'm not missing something, all the patches discussed here are
Hello Michael,
01.10.2024 05:07, Michael Paquier wrote:
On Mon, Sep 30, 2024 at 10:07:55AM +0900, Michael Paquier wrote:
...
And done this part.
If I'm not missing something, all the patches discussed here are committed
now, so maybe I've encountered a new anomaly.
Please try the following sc
as query IDs are only reported for the top queries, and we can
> do a scan of pg_stat_activity to see if the query ID is set. The
> assertion was getting more complicated, so I have hidden that behind a
> macro in execMain.c. All that should complete this project.
And done this part.
the test case cannot use a transaction
block as query IDs are only reported for the top queries, and we can
do a scan of pg_stat_activity to see if the query ID is set. The
assertion was getting more complicated, so I have hidden that behind a
macro in execMain.c. All that should complete this
> I am not sure. The GUCs pretty much enforce this behavior and I doubt
> that these are going to break moving on. Of course they would, but we
> are usually careful enough about that as long as it is possible to
> grep for them. For example see the BRIN case in pageinspect.
Yes, I see pageinspect
On Thu, Sep 26, 2024 at 10:55:37PM +, Imseih (AWS), Sami wrote:
> Sorry about my last reply. Not sure what happened with my email client.
> Here it is again.
No worries.
> glad to see the asserts are working as expected ad finding these issues.
> I took a look at the patch and tested it. It l
> Attached is the patch I am finishing with, with some new tests for
> BRIN and btree to force parallel builds with immutable expressions
> through functions.
Sorry about my last reply. Not sure what happened with my email client.
Here it is again.
glad to see the asserts are working as expected
telling us that we are not setting a query ID when doing a parallel
> btree build. The query string that we would report at the beginning
> of _bt_parallel_build_main() is passed down as a parameter, but not
> the query ID. Hence pg_stat_activity would report a NULL query ID
> wh
ssertion is doing the job I want it to do, because it is
telling us that we are not setting a query ID when doing a parallel
btree build. The query string that we would report at the beginning
of _bt_parallel_build_main() is passed down as a parameter, but not
the query ID. Hence pg_stat_activit
Hello Michael and Sami,
18.09.2024 08:46, Michael Paquier wrote:
So, I have applied 0001 down to 14, followed by 0002 on HEAD.
Please look at the script, which triggers Assert added by 24f520594:
(assuming shared_preload_libraries=pg_stat_statements)
SELECT repeat('x', 100) INTO t FROM genera
On Wed, Sep 18, 2024 at 03:14:07PM -0500, Sami Imseih wrote:
> Agree, will do start a new thread.
Thanks.
--
Michael
signature.asc
Description: PGP signature
> By the way, with the main issue fixed as of 933848d16dc9, could it be
> possible to deal with the plan cache part in a separate thread? This
> is from the start a separate thread to me, and we've done quite a bit
> here already.
Agree, will do start a new thread.
--
Sami
> So, I have applied 0001 down to 14, followed by 0002 on HEAD.
Thank you!
> 0002 is going to be interesting to see moving forward. I am wondering
> how existing out-of-core extensions will react on that and if it will
> help catching up any issues. So, let's see how the experiment goes
> with HE
On Wed, Sep 18, 2024 at 09:38:32AM +0900, Michael Paquier wrote:
> FWIW, I was thinking about something like what has been done in
> indexcmds.c for 5bbdfa8a18dc as the query ID value is not predictible
> across releases, but we could see whether it is set or not.
By the way, with the main issue f
On Wed, Sep 18, 2024 at 07:50:27AM +0900, Michael Paquier wrote:
> On Tue, Sep 17, 2024 at 05:01:18PM -0500, Sami Imseih wrote:
> > > Then, please see attached two lightly-updated patches. 0001 is for a
> > > backpatch down to v14. This is yours to force things in the exec and
> > > bind messages f
On Tue, Sep 17, 2024 at 06:39:17PM -0500, Sami Imseih wrote:
> FWIW, I do like the INJECTION_POINT idea and actually mentioned something
> similar up the thread [1] for the revalidate cache case, but I can see it
> being applied
> to all the other places we expect the queryId to be set.
>
> [1]
> would help to grab a query ID. A second option I have in mind would
> be to set up an injection point that produces a NOTICE if a query ID
> is set when we end processing an execute message, then check the
> number of NOTICE messages produced as these can be predictible
> depending on the number
quot;backpatch" instead of "backpatck".
Yes, I've noticed this one last Friday and fixed the typo in the
commit log after sending the previous patch series.
> That leaves us with considering v5-0002 [1]. I do think this is good
> for overall correctness of the queryId being
k this is good
for overall correctness of the queryId being advertised after a cache
revalidation, even if users of pg_stat_activity will hardly notice this.
[1]
https://www.postgresql.org/message-id/DB325894-3EE3-4B2E-A18C-4B34E7B2F5EC%40gmail.com
Regards,
Sami
On Wed, Sep 11, 2024 at 09:00:33AM -0400, Robert Haas wrote:
> On Tue, Sep 10, 2024 at 4:58 PM Noah Misch wrote:
> > ... a rule of "each wait event appears in one
> > pgstat_report_wait_start()" would be a rule I don't want.
>
> As the original committer of the wait event stuff, I intended for th
cted/extended.out
index bc8cb3f141..04a0594337 100644
--- a/contrib/pg_stat_statements/expected/extended.out
+++ b/contrib/pg_stat_statements/expected/extended.out
@@ -1,5 +1,13 @@
-- Tests with extended query protocol
SET pg_stat_statements.track_utility = FALSE;
+-- This test checks that an exec
> Do you think that we'd better replace the calls reporting the query ID
> in execMain.c by some assertions on HEAD? This won't work for
> ExecutorStart() because PREPARE statements (or actually EXECUTE,
> e.g. I bumped on that yesterday but I don't recall which one) would
Yes, adding the asserts
On Wed, Sep 11, 2024 at 09:41:58PM -0500, Sami Imseih wrote:
>> The tests in pg_stat_statements are one part I'm pretty sure is one
>> good way forward. It is not perfect, but with the psql meta-commands
>
> I played around with BackgrounsPsql. It works and gives us more flexibility
> in testing,
> After sleeping on it, I'd tend to slightly favor the last option in
> the back-branches and the second option on HEAD where we reduce the
> number of report calls. This way, we are a bit more careful in
>released branches by being more aggressive in reporting the query ID.
I agree with this beca
On Wed, Sep 11, 2024 at 02:29:49PM -0700, Jacob Champion wrote:
> On Mon, Sep 9, 2024 at 10:30 PM Michael Paquier wrote:
>> No. My question was about splitting pgstat_bestart() and
>> pgstat_bestart_pre_auth() in a cleaner way, because authenticated
>> connections finish by calling both, meaning
On Wed, Sep 11, 2024 at 05:02:07PM -0500, Sami Imseih wrote:
> In your 0003-Report-query-ID-for-execute-fetch-in-extended-query-.patch
> patch, you are still setting the queryId inside exec_execute_message
> if (execute_is_fetch). This condition could be removed and don't need to set
> the query
t that's not everything.
> 2) A query executed through a portal with tuples to return in a
> tuplestore also miss the query ID report. For example, a DML
> RETURNING with the extended protocol would use an execute (with
> ExecutorStart and ExecutorRun) followed by a series of exec
points
> proposed, though. It checks that the "authenticating" flag is set in
> pg_stat_activity, but it does nothing else. That seems limited. Or
> are you planning for more?
I can test for specific contents of the entry, if you'd like. My
primary goal was to test tha
On Tue, Sep 10, 2024 at 4:58 PM Noah Misch wrote:
> ... a rule of "each wait event appears in one
> pgstat_report_wait_start()" would be a rule I don't want.
As the original committer of the wait event stuff, I intended for the
rule that you do not want to be the actual rule. However, I see that
t. For example, a DML
RETURNING with the extended protocol would use an execute (with
ExecutorStart and ExecutorRun) followed by a series of execute fetch.
pg_stat_activity would report the query ID for the execute, not for
the fetches, while pg_stat_activity has the query string. That's
c
g by adding
different problems into the mix that require different analysis and
actions. Let's only focus on the issue that the query ID reporting
in pg_stat_activity is missing for the extended query protocol here.
--
Michael
signature.asc
Description: PGP signature
1 - 100 of 453 matches
Mail list logo
