Thread: Issue in recent pg_stat_statements?

Issue in recent pg_stat_statements?

From
David Christensen
Date:
-hackers,

So in doing some recent work on pg_stat_statements, I notice that while the regression test still passes on HEAD, it appears that 4f0b096 (per git bisect) changed/broke how this works compared to historical versions.

Essentially, when doing a fresh install of pg_stat_statements on a new fresh db (outside of the regression framework), it's not returning any rows from the view.  I didn't see any related documentation changes, so as far as I know, this should still be recording all statements as per normal.

My full steps to reproduce from a clean Centos 7 install are attached.  I have also been able to reproduce this on OS X and Fedora 33.  The TL;DR is:

CREATE EXTENSION pg_stat_statements;
CREATE TABLE foo (a int, b text);
INSERT INTO foo VALUES (1,'a');
SELECT * FROM foo;
SELECT * FROM pg_stat_statements; -- returns nothing

Settings for pg_stat_statements:
postgres=# select name, setting from pg_settings where name like 'pg_stat_statements%';
               name                | setting
-----------------------------------+---------
 pg_stat_statements.max            | 5000
 pg_stat_statements.save           | on
 pg_stat_statements.track          | top
 pg_stat_statements.track_planning | off
 pg_stat_statements.track_utility  | on
(5 rows)

Is this an expected change, or is this in fact broken?  In previous revisions, this was showing the INSERT and SELECT at the very least.  I'm unclear as to why the regression test is still passing, so want to verify that I'm not doing something wrong in the testing.

Best,

David
Attachment

Re: Issue in recent pg_stat_statements?

From
Magnus Hagander
Date:
On Mon, Apr 26, 2021 at 5:15 PM David Christensen
<david.christensen@crunchydata.com> wrote:
>
> -hackers,
>
> So in doing some recent work on pg_stat_statements, I notice that while the regression test still passes on HEAD, it
appearsthat 4f0b096 (per git bisect) changed/broke how this works compared to historical versions. 
>
> Essentially, when doing a fresh install of pg_stat_statements on a new fresh db (outside of the regression
framework),it's not returning any rows from the view.  I didn't see any related documentation changes, so as far as I
know,this should still be recording all statements as per normal. 
>
> My full steps to reproduce from a clean Centos 7 install are attached.  I have also been able to reproduce this on OS
Xand Fedora 33.  The TL;DR is: 
>
> CREATE EXTENSION pg_stat_statements;
> CREATE TABLE foo (a int, b text);
> INSERT INTO foo VALUES (1,'a');
> SELECT * FROM foo;
> SELECT * FROM pg_stat_statements; -- returns nothing
>
> Settings for pg_stat_statements:
> postgres=# select name, setting from pg_settings where name like 'pg_stat_statements%';
>                name                | setting
> -----------------------------------+---------
>  pg_stat_statements.max            | 5000
>  pg_stat_statements.save           | on
>  pg_stat_statements.track          | top
>  pg_stat_statements.track_planning | off
>  pg_stat_statements.track_utility  | on
> (5 rows)
>
> Is this an expected change, or is this in fact broken?  In previous revisions, this was showing the INSERT and SELECT
atthe very least.  I'm unclear as to why the regression test is still passing, so want to verify that I'm not doing
somethingwrong in the testing. 

Yes, you want to look into the queryid functionality. See
https://www.postgresql.org/message-id/flat/35457b09-36f8-add3-1d07-6034fa585ca8%40oss.nttdata.com

Interface changes may still be coming in 14 for that. Or warnings.


--
 Magnus Hagander
 Me: https://www.hagander.net/
 Work: https://www.redpill-linpro.com/



Re: Issue in recent pg_stat_statements?

From
David Christensen
Date:
> Is this an expected change, or is this in fact broken?  In previous revisions, this was showing the INSERT and SELECT at the very least.  I'm unclear as to why the regression test is still passing, so want to verify that I'm not doing something wrong in the testing.

Yes, you want to look into the queryid functionality. See
https://www.postgresql.org/message-id/flat/35457b09-36f8-add3-1d07-6034fa585ca8%40oss.nttdata.com

Interface changes may still be coming in 14 for that. Or warnings.

Hmm, I'm unclear as to why you would potentially want to use pg_stat_statements *without* this functionality.  At the very least, it violates POLA — I spent the better part of a day thinking this was a bug due to the expected behavior being so obvious I wouldn't have expected any different.

In any case, this discussion is better had on a different thread.  Thanks at least for explaining what I was seeing.

Best,

David

Re: Issue in recent pg_stat_statements?

From
Julien Rouhaud
Date:
On Mon, Apr 26, 2021 at 11:40 PM David Christensen
<david.christensen@crunchydata.com> wrote:
>>
>> > Is this an expected change, or is this in fact broken?  In previous revisions, this was showing the INSERT and
SELECTat the very least.  I'm unclear as to why the regression test is still passing, so want to verify that I'm not
doingsomething wrong in the testing. 
>>
>> Yes, you want to look into the queryid functionality. See
>> https://www.postgresql.org/message-id/flat/35457b09-36f8-add3-1d07-6034fa585ca8%40oss.nttdata.com
>>
>> Interface changes may still be coming in 14 for that. Or warnings.
>
>
> Hmm, I'm unclear as to why you would potentially want to use pg_stat_statements *without* this functionality.

Using pg_stat_statements with a different query_id semantics without
having to fork pg_stat_statements.



Re: Issue in recent pg_stat_statements?

From
David Christensen
Date:


On Mon, Apr 26, 2021 at 12:18 PM Julien Rouhaud <rjuju123@gmail.com> wrote:
On Mon, Apr 26, 2021 at 11:40 PM David Christensen
<david.christensen@crunchydata.com> wrote:
>>
>> > Is this an expected change, or is this in fact broken?  In previous revisions, this was showing the INSERT and SELECT at the very least.  I'm unclear as to why the regression test is still passing, so want to verify that I'm not doing something wrong in the testing.
>>
>> Yes, you want to look into the queryid functionality. See
>> https://www.postgresql.org/message-id/flat/35457b09-36f8-add3-1d07-6034fa585ca8%40oss.nttdata.com
>>
>> Interface changes may still be coming in 14 for that. Or warnings.
>
>
> Hmm, I'm unclear as to why you would potentially want to use pg_stat_statements *without* this functionality.

Using pg_stat_statements with a different query_id semantics without
having to fork pg_stat_statements.

I can see that argument for allowing alternatives, but the current default of nothing seems to be particularly non-useful, so some sensible default value would seem to be in order, or I can predict a whole mess of future user complaints.


Re: Issue in recent pg_stat_statements?

From
Andres Freund
Date:
On 2021-04-26 12:53:30 -0500, David Christensen wrote:
> On Mon, Apr 26, 2021 at 12:18 PM Julien Rouhaud <rjuju123@gmail.com> wrote:
> > Using pg_stat_statements with a different query_id semantics without
> > having to fork pg_stat_statements.
> >
> 
> I can see that argument for allowing alternatives, but the current default
> of nothing seems to be particularly non-useful, so some sensible default
> value would seem to be in order, or I can predict a whole mess of future
> user complaints.

+1



Re: Issue in recent pg_stat_statements?

From
David Christensen
Date:
Andres Freund writes:

> On 2021-04-26 12:53:30 -0500, David Christensen wrote:
>> On Mon, Apr 26, 2021 at 12:18 PM Julien Rouhaud <rjuju123@gmail.com> wrote:
>> > Using pg_stat_statements with a different query_id semantics without
>> > having to fork pg_stat_statements.
>> >
>> 
>> I can see that argument for allowing alternatives, but the current default
>> of nothing seems to be particularly non-useful, so some sensible default
>> value would seem to be in order, or I can predict a whole mess of future
>> user complaints.
>
> +1

Just doing some routine followup here; it looks like cafde58b33 fixes
this issue.

Thanks!

David