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
|
Список | 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 по дате отправления: