Re: Assertion failure on PG15 with modified test_shm_mq test
От | Pavan Deolasee |
---|---|
Тема | Re: Assertion failure on PG15 with modified test_shm_mq test |
Дата | |
Msg-id | CABOikdMnRTdnMq=TEfVyMzj_C6r580NmcWPHrAnxuk4HYN8G2w@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Assertion failure on PG15 with modified test_shm_mq test (Andres Freund <andres@anarazel.de>) |
Ответы |
Re: Assertion failure on PG15 with modified test_shm_mq test
|
Список | pgsql-hackers |
Hi,
On Thu, Aug 18, 2022 at 5:38 AM Andres Freund <andres@anarazel.de> wrote:
I don't think we have the infrastructure for a nice solution to this at the
moment - we need a fairly large overhaul of process initialization / shutdown
to handle these interdependencies nicely.
Ok, understood.
We can't move pgstat shutdown into on_dsm callback because that's too late to
allocate *new* dsm segments, which we might need to do while flushing
out pending stats.
See https://git.postgresql.org/gitweb/?p=postgresql.git;a=commit;h=fa91d4c91f28f4819dc54f93adbd413a685e366a
for a way to avoid the problem.
Thanks for the hint. I will try that approach. I wonder though if there is something more we can do. For example, would it make sense to throw a WARNING and avoid segfault if pgstat machinery is already shutdown? Just worried if the code can be reached from multiple paths and testing all of those would be difficult for extension developers, especially given this may happen in error recovery path.
Thanks,
Pavan
Pavan Deolasee
EnterpriseDB: https://www.enterprisedb..com
В списке pgsql-hackers по дате отправления: