Re: Ignore 2PC transaction GIDs in query jumbling

On Sun, Aug 13, 2023 at 02:48:22PM +0800, Julien Rouhaud wrote:
> On Sun, Aug 13, 2023 at 03:25:33PM +0900, Michael Paquier wrote:
>> Perhaps not as much, actually, because I was just reminded that
>> DEALLOCATE is something that pg_stat_statements ignores. So this
>> makes harder the introduction of tests.
>
> Maybe it's time to revisit that? According to [1] the reason why
> pg_stat_statements currently ignores DEALLOCATE is because it indeed bloated
> the entries but also because at that time the suggestion for jumbling only this
> one was really hackish.

Good point. The argument of the other thread does not really hold
much these days now that query jumbling can happen for all the utility
nodes.

> Now that we do have a sensible approach to jumble utility statements, I think
> it would be beneficial to be able to track those, for instance to be easily
> diagnose a driver that doesn't rely on the extended protocol.

Fine by me. Would you like to write a patch? I've begun typing an
embryon of patch a few days ago, and did not look yet at the rest.
Please see the attached.

>> Anyway, I guess that your own
>> extension modules have a need for a query ID compiled with these
>> fields ignored?
>
> My module has a need to track statements and still work efficiently after that.
> So anything that can lead to virtually an infinite number of pg_stat_statements
> entries is a problem for me, and I guess to all the other modules / tools that
> track pg_stat_statements. I guess the reason why my module is still ignoring
> DEALLOCATE is because it existed before pg 9.4 (with a homemade queryid as it
> wasn't exposed before that), and it just stayed there since with the rest of
> still problematic statements.

Yeah, probably.
--
Michael