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