Re: select_parallel test failure: gather sometimes losing tuples(maybe during rescans)?

Поиск
Список
Период
Сортировка
От Thomas Munro
Тема Re: select_parallel test failure: gather sometimes losing tuples(maybe during rescans)?
Дата
Msg-id CAEepm=2m-icXU5n3KXsC+bpEFwK76Nbag2g7GPsMGC-KTq8yAQ@mail.gmail.com
обсуждение исходный текст
Ответ на Re: select_parallel test failure: gather sometimes losing tuples(maybe during rescans)?  (Thomas Munro <thomas.munro@enterprisedb.com>)
Ответы Re: select_parallel test failure: gather sometimes losing tuples(maybe during rescans)?  (Tomas Vondra <tomas.vondra@2ndquadrant.com>)
Список pgsql-hackers
On Sun, Mar 4, 2018 at 5:40 PM, Thomas Munro
<thomas.munro@enterprisedb.com> wrote:
> Could shm_mq_detach_internal() need a pg_write_barrier() before it
> writes mq_detached = true, to make sure that anyone who observes that
> can also see the most recent increase of mq_bytes_written?

I can reproduce both failure modes (missing tuples and "lost contact")
in the regression database with the attached Python script on my Mac.
It takes a few minutes and seems to be happen sooner when my machine
is also doing other stuff (playing debugging music...).

I can reproduce it at 34db06ef9a1d7f36391c64293bf1e0ce44a33915
"shm_mq: Reduce spinlock usage." but (at least so far) not at the
preceding commit.

I can fix it with the following patch, which writes XXX out to the log
where it would otherwise miss a final message sent just before
detaching with sufficiently bad timing/memory ordering.  This patch
isn't my proposed fix, it's just a demonstration of what's busted.
There could be a better way to structure things than this.

-- 
Thomas Munro
http://www.enterprisedb.com

Вложения

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

Предыдущее
От: Fabien COELHO
Дата:
Сообщение: Re: pgbench - allow to specify scale as a size
Следующее
От: Magnus Hagander
Дата:
Сообщение: Re: select_parallel test failure: gather sometimes losing tuples(maybe during rescans)?