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