Re: pgsql: pgstat: Bring up pgstat in BaseInit() to fix uninitialized use o

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: pgsql: pgstat: Bring up pgstat in BaseInit() to fix uninitialized use o
Дата
Msg-id 2788096.1628363558@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: pgsql: pgstat: Bring up pgstat in BaseInit() to fix uninitialized use o  (Andres Freund <andres@anarazel.de>)
Ответы Re: pgsql: pgstat: Bring up pgstat in BaseInit() to fix uninitialized use o  (Andres Freund <andres@anarazel.de>)
Список pgsql-committers
Andres Freund <andres@anarazel.de> writes:
> On 2021-08-07 13:37:16 -0400, Tom Lane wrote:
>> Depends what you want to define as a bug.  What I am not happy about
>> is the prospect of random assertion failures for the next six months
>> while you finish redesigning half of the system.  The rest of us
>> have work we want to get done, too.  I don't object to the idea of
>> making no-lost-events an end goal, but we are clearly not ready
>> for that today.

> I don't know what to do about that. How would we even find these cases if they
> aren't hit during regression tests on my machine (nor on a lot of others)?

The regression tests really aren't that helpful for testing the problem
scenario here, which basically is SIGTERM'ing a query-in-progress.
I'm rather surprised that the buildfarm managed to exercise that at all.

You might try setting up a test scaffold that runs the core regression
tests and SIGINT's the postmaster, or alternatively SIGTERM's some
individual session, at random times partway through.  Obviously this
will make the regression tests report failure, but what to look for
is if anything dumps core on the way out.

            regards, tom lane



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

Предыдущее
От: Andres Freund
Дата:
Сообщение: Re: pgsql: pgstat: Bring up pgstat in BaseInit() to fix uninitialized use o
Следующее
От: Andres Freund
Дата:
Сообщение: Re: pgsql: pgstat: Bring up pgstat in BaseInit() to fix uninitialized use o