On Thu, Mar 3, 2016 at 1:10 AM, Tom Lane <t...@sss.pgh.pa.us> wrote: > Noah Misch <n...@leadboat.com> writes: >> I've modified buildfarm member mandrill to use force_parallel_mode=regress >> and >> max_parallel_degree=5; a full run passes. We'll now see if it intermittently >> fails the stats test, like Tom witnessed: >> http://www.postgresql.org/message-id/30385.1456077...@sss.pgh.pa.us > > http://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=mandrill&dt=2016-03-02%2023%3A34%3A10
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. 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. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
wait-for-trunc-stats.patch
Description: application/download
-- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
