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
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 |