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  (Tom Lane <tgl@sss.pgh.pa.us>)
Список 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 по дате отправления:

Предыдущее
От: Mark Dilger
Дата:
Сообщение: Re: improving GROUP BY estimation
Следующее
От: Robert Haas
Дата:
Сообщение: Re: WIP: Upper planner pathification