Re: Assertion failure on PG15 with modified test_shm_mq test

From: Pavan Deolasee <pavan(dot)deolasee(at)gmail(dot)com>
To: Andres Freund <andres(at)anarazel(dot)de>
Cc: PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Assertion failure on PG15 with modified test_shm_mq test
Date: 2022-08-18 11:28:24
Message-ID: CABOikdMnRTdnMq=TEfVyMzj_C6r580NmcWPHrAnxuk4HYN8G2w@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi,

On Thu, Aug 18, 2022 at 5:38 AM Andres Freund <andres(at)anarazel(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Amit Kapila 2022-08-18 11:44:59 Re: Perform streaming logical transactions by background workers and parallel apply
Previous Message Daniel Gustafsson 2022-08-18 11:24:20 Re: TAP output format in pg_regress