Robert Haas <robertmh...@gmail.com> writes:
> A couple of my colleagues have been looking into this. It's not
> entirely clear to me what's going on here yet, but it looks like the
> stats get there if you wait long enough. Rahila Syed was able to
> reproduce the problem and says that the attached patch fixes it. But
> I don't quite understand why this should fix it.
I don't like this patch much. While the new function is not bad in
itself, it looks really weird to call it immediately after the other
wait function. And the reason for that, AFAICT, is that somebody dropped
the entire "truncation stats" test sequence into the middle of unrelated
tests, evidently in the vain hope that that way they could piggyback
on the existing wait. Which these failures are showing us is wrong.
I think we should move all the inserted logic down so that it's not in the
middle of unrelated testing.
> BTW, this comment is obsolete:
> -- force the rate-limiting logic in pgstat_report_tabstat() to time out
> -- and send a message
> SELECT pg_sleep(1.0);
> pg_sleep
> ----------
> (1 row)
> That function was renamed in commit
> 93c701edc6c6f065cd25f77f63ab31aff085d6ac, but apparently Tom forgot to
> grep for other uses of that identifier name.
Duh :-(. Actually, do we need that sleep at all anymore? Seems like
wait_for_stats ought to cover it.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
