Re: a raft of parallelism-related bug fixes

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: a raft of parallelism-related bug fixes
Дата
Msg-id 30385.1456077923@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: a raft of parallelism-related bug fixes  (Robert Haas <robertmhaas@gmail.com>)
Список pgsql-hackers
Robert Haas <robertmhaas@gmail.com> writes:
> On Mon, Feb 8, 2016 at 2:36 PM, Joshua D. Drake <jd@commandprompt.com> wrote:
>> I have no problem running any test cases you wish on a branch in a loop for
>> the next week and reporting back any errors.

> Well, what I've done is push into the buildfarm code that will allow
> us to do *the most exhaustive* testing that I know how to do in an
> automated fashion. Which is to create a file that says this:

> force_parallel_mode=regress
> max_parallel_degree=2

I did a few dozen runs of the core regression tests with those settings
(using current HEAD plus my lockGroupLeaderIdentifier-ectomy patch).
Roughly one time in ten, it fails in the stats test, with diffs as
attached.  I interpret this as meaning that parallel workers don't
reliably transmit stats to the stats collector, though maybe there
is something else happening.

            regards, tom lane

*** /home/postgres/pgsql/src/test/regress/expected/stats.out    Wed Mar  4 00:55:25 2015
--- /home/postgres/pgsql/src/test/regress/results/stats.out    Sun Feb 21 12:59:27 2016
***************
*** 148,158 ****
   WHERE relname like 'trunc_stats_test%' order by relname;
        relname      | n_tup_ins | n_tup_upd | n_tup_del | n_live_tup | n_dead_tup
  -------------------+-----------+-----------+-----------+------------+------------
!  trunc_stats_test  |         3 |         0 |         0 |          0 |          0
!  trunc_stats_test1 |         4 |         2 |         1 |          1 |          0
!  trunc_stats_test2 |         1 |         0 |         0 |          1 |          0
!  trunc_stats_test3 |         4 |         0 |         0 |          2 |          2
!  trunc_stats_test4 |         2 |         0 |         0 |          0 |          2
  (5 rows)

  SELECT st.seq_scan >= pr.seq_scan + 1,
--- 148,158 ----
   WHERE relname like 'trunc_stats_test%' order by relname;
        relname      | n_tup_ins | n_tup_upd | n_tup_del | n_live_tup | n_dead_tup
  -------------------+-----------+-----------+-----------+------------+------------
!  trunc_stats_test  |         0 |         0 |         0 |          0 |          0
!  trunc_stats_test1 |         0 |         0 |         0 |          0 |          0
!  trunc_stats_test2 |         0 |         0 |         0 |          0 |          0
!  trunc_stats_test3 |         0 |         0 |         0 |          0 |          0
!  trunc_stats_test4 |         0 |         0 |         0 |          0 |          0
  (5 rows)

  SELECT st.seq_scan >= pr.seq_scan + 1,

======================================================================


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: Re: [COMMITTERS] pgsql: Introduce group locking to prevent parallel processes from deadl
Следующее
От: Stephen Frost
Дата:
Сообщение: Re: [COMMITTERS] pgsql: Cosmetic improvements in new config_info code.