subscription/026_stats test is intermittently slow?

Поиск
Список
Период
Сортировка
От Robert Haas
Тема subscription/026_stats test is intermittently slow?
Дата
Msg-id CA+TgmoZkj=A39i4obKXADMhzJW=6dyGq-C1aGfb+jUy9XvxwYA@mail.gmail.com
обсуждение исходный текст
Ответы Re: subscription/026_stats test is intermittently slow?  (Michael Paquier <michael@paquier.xyz>)
Re: subscription/026_stats test is intermittently slow?  (Andres Freund <andres@anarazel.de>)
Список pgsql-hackers
I just did a run of the regression test where this test was the last
one to finish by quite a lot. Key log entries:

[13:35:48.583](0.039s) # initializing database system by copying initdb template
...
[13:35:52.397](0.108s) ok 5 - Check reset timestamp for
'test_tab1_sub' is newer after second reset.

#### Begin standard error

psql:<stdin>:1: NOTICE:  created replication slot "test_tab2_sub" on publisher

#### End standard error

Waiting for replication conn test_tab2_sub's replay_lsn to pass
0/151E8C8 on publisher

done

[13:38:53.706](181.310s) ok 6 - Check that table 'test_tab2' now has 1 row.
...
[13:38:54.344](0.294s) 1..13

I reran the test and it looks very different:

[13:54:01.703](0.090s) ok 5 - Check reset timestamp for
'test_tab1_sub' is newer after second reset.
...
Waiting for replication conn test_tab2_sub's replay_lsn to pass
0/151E900 on publisher
...
[13:54:03.006](1.303s) ok 6 - Check that table 'test_tab2' now has 1 row.

It looks to me like in the first run it took 3 minutes for the
replay_lsn to catch up to the desired value, and in the second run,
two seconds. I think I have seen previous instances where something
similar happened, although in those cases I did not stop to record any
details. Have others seen this? Is there something we can/should do
about it?

-- 
Robert Haas
EDB: http://www.enterprisedb.com



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

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: Support event trigger for logoff
Следующее
От: Robert Haas
Дата:
Сообщение: Re: WIP Incremental JSON Parser