Re: [HACKERS] intermittent failures in Cygwin from select_parallel tests

Поиск
Список
Период
Сортировка
От Robert Haas
Тема Re: [HACKERS] intermittent failures in Cygwin from select_parallel tests
Дата
Msg-id CA+TgmobV54G+dOssGdeAC29RWDw5Dqr66SxrWhCsvq8=Jt5UDg@mail.gmail.com
обсуждение исходный текст
Ответ на Re: [HACKERS] intermittent failures in Cygwin from select_parallel tests  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: [HACKERS] intermittent failures in Cygwin from select_parallel tests  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
On Wed, Jun 14, 2017 at 6:01 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> I wrote:
>> But surely the silent treatment should only apply to DSM_OP_CREATE?
>
> Oh ... scratch that, it *does* only apply to DSM_OP_CREATE.
>
> The lack of any other message before the 'could not map' failure must,
> then, mean that dsm_attach() couldn't find an entry in shared memory
> that it wanted to attach to.  But how could that happen?

Well, as Amit points out, there are entirely legitimate ways for that
to happen.  If the leader finishes the whole query itself before the
worker reaches the dsm_attach() call, it will call dsm_detach(),
destroying the segment, and the worker will hit this ERROR.  That
shouldn't happen very often in the real world, because we ought not to
select a parallel plan in the first place unless the query is going to
take a while to run, but the select_parallel test quite deliberately
disarms all of the guards that would tend to discourage such plans.

Of course, as Amit also points out, it could also be the result of
some bug, but I'm not sure we have any reason to think so.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company



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

Предыдущее
От: Peter Eisentraut
Дата:
Сообщение: Re: [HACKERS] Refreshing subscription relation state inside atransaction block
Следующее
От: Tom Lane
Дата:
Сообщение: Re: [HACKERS] intermittent failures in Cygwin from select_parallel tests