Re: Parallel query fails on standby server

Поиск
Список
Период
Сортировка
От Michael Paquier
Тема Re: Parallel query fails on standby server
Дата
Msg-id CAB7nPqTtUG=uLWvnXRA-xVyuXyvhKvQDPYdc4-NR5dqpNDr1+g@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Parallel query fails on standby server  (Robert Haas <robertmhaas@gmail.com>)
Список pgsql-hackers
On Wed, Mar 9, 2016 at 12:34 AM, Robert Haas <robertmhaas@gmail.com> wrote:
> On Tue, Mar 8, 2016 at 8:23 AM, Michael Paquier
> <michael.paquier@gmail.com> wrote:
>> On Tue, Mar 8, 2016 at 9:51 PM, Craig Ringer <craig@2ndquadrant.com> wrote:
>>> On 8 March 2016 at 20:30, Ashutosh Sharma <ashu.coek88@gmail.com> wrote:
>>>>
>>>> While testing a parallel scan feature on standby server, it is found that
>>>> the parallel query fails with an error "ERROR:  failed to initialize
>>>> transaction_read_only to 0".
>>>>
>>>
>>> Looks like it might be a good idea to add some tests to src/test/recovery
>>> for parallel query on standby servers...
>>
>> An even better thing would be a set of read-only tests based on the
>> database "regression" generated by make check, itself run with
>> pg_regress.
>
> I'm not sure anything in the main regression suite actually goes
> parallel right now, which is probably the first thing to fix.
>
> Unless, of course, you use force_parallel_mode=regress, max_parallel_degree>0.

I was thinking about a test in src/test/recovery, that runs a standby
and a master. pg_regress with the main recovery test suite is run on
the master, then a second pg_regress run happens with a set of
read-only queries, set with sql/expected located in src/test/recovery
directly for example. Do we actually have a buildfarm animal using
those parameters in extra_config?
-- 
Michael



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

Предыдущее
От: Michael Paquier
Дата:
Сообщение: Re: Recovery test failure for recovery_min_apply_delay on hamster
Следующее
От: Amit Langote
Дата:
Сообщение: Re: [PROPOSAL] VACUUM Progress Checker.