Re: BUG #17146: pg_dump statements are going into pg_stat_statements in 13.4 - Mailing list pgsql-bugs

From James Inform
Subject Re: BUG #17146: pg_dump statements are going into pg_stat_statements in 13.4
Date
Msg-id 9586ada6-344e-ff26-8c16-6c847a984220@pharmapp.de
Whole thread Raw
In response to Re: BUG #17146: pg_dump statements are going into pg_stat_statements in 13.4  (Julien Rouhaud <rjuju123@gmail.com>)
List pgsql-bugs
That's strange.
I see those copy commands it pg_stat_statments and they have 1 calls. 
The backup job runs once a day since many months. I would expect to see 
calls > 1 then.

So again very strange, but maybe a layer 8 problem :)

  I will recheck.


Julien Rouhaud Wrote:
> On Mon, Aug 16, 2021 at 4:46 PM PG Bug reporting form
> <noreply@postgresql.org> wrote:
>> The following bug has been logged on the website:
>>
>> I have just updated to 13.4 and I have noticed that "COPY" statements that
>> are produced by pg_dump appear in pg_stat_statements view.
>>
>> You can imagine that the copy statements are slower than all my other
>> statements, so they come up as the first and most expensive statements in
>> pg_stat_statements.
> You could order by the average execution time rather than the total
> execution time and/or filter out queries executed less than X times,
> it's more likely to give you low hanging fruits.
>
>> This is a new behaviour in 13.4 and hasn't existed in 13.3 and prior.
> Nothing changed here for a long time.
>
>> Is there a setting to prevent this?
> You could disable pg_stat_statements.track_utility, but it obviously
> means that all utility statements will be ignored, not only COPY.




pgsql-bugs by date:

Previous
From: Julien Rouhaud
Date:
Subject: Re: BUG #17145: Invalid memory alloc request size, when searching in text column with big content > 250MB
Next
From: Julien Rouhaud
Date:
Subject: Re: BUG #17146: pg_dump statements are going into pg_stat_statements in 13.4