From: | Sami Imseih <samimseih(at)gmail(dot)com> |
---|---|
To: | Michael Paquier <michael(at)paquier(dot)xyz> |
Cc: | jian he <jian(dot)universality(at)gmail(dot)com>, Anthonin Bonnefoy <anthonin(dot)bonnefoy(at)datadoghq(dot)com>, "Imseih (AWS), Sami" <simseih(at)amazon(dot)com>, Andrei Lepikhov <lepihov(at)gmail(dot)com>, kaido vaikla <kaido(dot)vaikla(at)gmail(dot)com>, "pgsql-hackers(at)lists(dot)postgresql(dot)org" <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: query_id, pg_stat_activity, extended query protocol |
Date: | 2024-09-12 02:41:58 |
Message-ID: | 881F766E-9CE9-484D-BB7D-6E416321567A@gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
> 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 because it will safely allow us to backpatch this
fix.
> 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, but I think the pg_stat_statements test are good enough for this
purpose.
My only concern is this approach tests core functionality ( reporting of queryId )
in the tests of a contrib module ( pg_stat_statements ). Is that a valid
concern?
> Perhaps. I'd need to think through this one. Let's do things in
> order and see about the reports for the bind/execute messages, first,
> please?
Sure, that is fine.
Regards,
Sami
From | Date | Subject | |
---|---|---|---|
Next Message | Tatsuo Ishii | 2024-09-12 02:42:06 | Re: Add memory/disk usage for WindowAgg nodes in EXPLAIN |
Previous Message | shawn wang | 2024-09-12 02:40:24 | Re: Trim the heap free memory |