Re: postgres_fdw vs. force_parallel_mode on ppc - Mailing list pgsql-hackers

From Robert Haas
Subject Re: postgres_fdw vs. force_parallel_mode on ppc
Date
Msg-id CA+Tgmob8vtnRDBK3PVhPOun9+iqb6OOjUVfynGwmiSuFRpksHg@mail.gmail.com
Whole thread Raw
In response to Re: postgres_fdw vs. force_parallel_mode on ppc  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: postgres_fdw vs. force_parallel_mode on ppc
List 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

Attachment

pgsql-hackers by date:

Previous
From: Mark Dilger
Date:
Subject: Re: improving GROUP BY estimation
Next
From: Robert Haas
Date:
Subject: Re: WIP: Upper planner pathification