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 (firstname.lastname@example.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers