Re: subscriptionCheck failures on nightjar

Поиск
Список
Период
Сортировка
От Andres Freund
Тема Re: subscriptionCheck failures on nightjar
Дата
Msg-id 20190920212603.7zlgrlwtdirbmuw7@alap3.anarazel.de
обсуждение исходный текст
Ответ на Re: subscriptionCheck failures on nightjar  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: subscriptionCheck failures on nightjar  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
Hi,

On 2019-09-20 16:25:21 -0400, Tom Lane wrote:
> Andres Freund <andres@anarazel.de> writes:
> > Since now a number of people (I tried as well), failed to reproduce this
> > locally, I propose that we increase the log-level during this test on
> > master. And perhaps expand the set of debugging information. With the
> > hope that the additional information on the cases encountered on the bf
> > helps us build a reproducer or, even better, diagnose the issue
> > directly.  If people agree, I'll come up with a patch.
> 
> I recreated my freebsd-9-under-qemu setup and I can still reproduce
> the problem, though not with high reliability (order of 1 time in 10).
> Anything particular you want logged?

A DEBUG2 log would help a fair bit, because it'd log some information
about what changes the "horizons" determining when data may be removed.

Perhaps with the additional elogs attached? I lowered some messages to
DEBUG2 so we don't have to suffer the noise of the ipc.c DEBUG3
messages.

If I use a TEMP_CONFIG setting log_min_messages=DEBUG2 with the patches
applied, the subscription tests still pass.

I hope they still fail on your setup, even though the increased logging
volume probably changes timing somewhat.

Greetings,

Andres Freund

Вложения

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

Предыдущее
От: "Castillo, Steven (Agile)"
Дата:
Сообщение: Hi guys, HELP please
Следующее
От: Tom Lane
Дата:
Сообщение: Re: subscriptionCheck failures on nightjar