Обсуждение: pg_stat_bgwriter broken?

I'm behind on my list mail so maybe this has been mentioned already, but 
when I just tried pg_stat_bgwriter from a build against today's HEAD I 
got this:

pgbench=# select count(*) FROM pg_stat_bgwriter;
ERROR:  did not find '}' at end of input node

Can someone confirm if this broke recently, or is it just me?  Last time 
I would have tested this myself was a few weeks ago.

Regardless, I was thinking of adding some basic sanity checking on this 
view, that runs from the regression tests to catch this class of problem 
in the future.  It's kind of sloppy that this and the bgwriter counter 
reset aren't tested as part of "make check".  I think these two would 
always produce stable results:

postgres=# SELECT count(*) FROM pg_stat_bgwriter;count
-------    1
postgres=# SELECT pg_stat_reset_shared('bgwriter');pg_stat_reset_shared
----------------------
(1 row)

And the first one of those is similarly broken on my install.  Thoughts 
on whether adding those to the regression tests would be a worthwhile 
patch?  I'll do the work, just thinking out loud about the concept.

-- 
Greg Smith   2ndQuadrant US    greg@2ndQuadrant.com   Baltimore, MD

Greg Smith <greg@2ndquadrant.com> writes:
> I'm behind on my list mail so maybe this has been mentioned already, but 
> when I just tried pg_stat_bgwriter from a build against today's HEAD I 
> got this:

> pgbench=# select count(*) FROM pg_stat_bgwriter;
> ERROR:  did not find '}' at end of input node

Worksforme.  You probably need a full recompile and/or initdb.
This is a typical symptom when someone adds a field to a parse node
type and you have code or stored rules that haven't been updated.
(Usually though we try to bump catversion when an initdb is needed
because of such a change.)
        regards, tom lane

Tom Lane wrote:
> Worksforme.  You probably need a full recompile and/or initdb

Yeah, sorry about the noise.  This went away after some more intensive 
rebuilding.  I think I still want to add some regression testing of this 
view as suggested.  If that had been there, I'd have been a lot more 
confident it was my mistake, and not something that just slipped through 
without being tested.

-- 
Greg Smith   2ndQuadrant US    greg@2ndQuadrant.com   Baltimore, MD

Greg Smith <greg@2ndquadrant.com> writes:
> Tom Lane wrote:
>> Worksforme.  You probably need a full recompile and/or initdb

> Yeah, sorry about the noise.  This went away after some more intensive 
> rebuilding.  I think I still want to add some regression testing of this 
> view as suggested.  If that had been there, I'd have been a lot more 
> confident it was my mistake, and not something that just slipped through 
> without being tested.

[ shrug... ]  That's one of the simplest views in the entire system.
It's very hard to conceive of a bug that would affect it and not other
views, *especially* such a bug that would be exposed by a test that
doesn't actually exercise the functionality, such as you're suggesting
here.

If the cause was what I suggested, most likely the other stats views
were broken too --- were you able to pass the regression tests in that
state?
        regards, tom lane

Tom Lane wrote:
> If the cause was what I suggested, most likely the other stats views
> were broken too --- were you able to pass the regression tests in that
> state?
>   

I was having a lot of problems with the system that included regression 
test issues, and yelped about this one earlier than I normally would 
because it was blocking work I wanted to get submitted today.  Sorry 
about the noise, and thanks for the info about why this was happening.  
The way you've explained it now, I see why it's not worth adding a 
specific regression test for this in the future, and what else I should 
have checked when I ran into my problem (that other system stats views 
were also working or not).

-- 
Greg Smith   2ndQuadrant US    greg@2ndQuadrant.com   Baltimore, MD
PostgreSQL Training, Services and Support        www.2ndQuadrant.us

Greg Smith <greg@2ndquadrant.com> writes:
> The way you've explained it now, I see why it's not worth adding a 
> specific regression test for this in the future, and what else I should 
> have checked when I ran into my problem (that other system stats views 
> were also working or not).

FWIW, I wouldn't object to a test that somehow exercised the specific
functionality of the view; I was just dubious that there was any value
in the sort of test you were suggesting.  We found ways to exercise the
table-counter stuff in a sufficiently reproducible way for the stats
test --- can you do something similar here?
        regards, tom lane