Re: postgres_fdw vs. force_parallel_mode on ppc
От | Robert Haas |
---|---|
Тема | Re: postgres_fdw vs. force_parallel_mode on ppc |
Дата | |
Msg-id | CA+Tgmob8vtnRDBK3PVhPOun9+iqb6OOjUVfynGwmiSuFRpksHg@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: postgres_fdw vs. force_parallel_mode on ppc (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: postgres_fdw vs. force_parallel_mode on ppc
|
Список | pgsql-hackers |
On Thu, Mar 3, 2016 at 1:10 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > Noah Misch <noah@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.1456077923@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
Вложения
В списке pgsql-hackers по дате отправления: