Обсуждение: Issue in recent pg_stat_statements?
-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
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)
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
Вложения
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/
> 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
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.
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.
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
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