Re: Assertion failure on PG15 with modified test_shm_mq test - Mailing list pgsql-hackers

From Pavan Deolasee
Subject Re: Assertion failure on PG15 with modified test_shm_mq test
Date
Msg-id CABOikdMnRTdnMq=TEfVyMzj_C6r580NmcWPHrAnxuk4HYN8G2w@mail.gmail.com
Whole thread Raw
In response to Re: Assertion failure on PG15 with modified test_shm_mq test  (Andres Freund <andres@anarazel.de>)
Responses Re: Assertion failure on PG15 with modified test_shm_mq test
List 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 by date:

Previous
From: Daniel Gustafsson
Date:
Subject: Re: TAP output format in pg_regress
Next
From: Amit Kapila
Date:
Subject: Re: Perform streaming logical transactions by background workers and parallel apply