Re: Non-robustness in pmsignal.c - Mailing list pgsql-hackers

From Andres Freund
Subject Re: Non-robustness in pmsignal.c
Date
Msg-id 20221008173236.gl6jtuxtqyihvywm@awork3.anarazel.de
Whole thread Raw
In response to Re: Non-robustness in pmsignal.c  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Non-robustness in pmsignal.c  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
Hi,

On 2022-10-08 13:15:07 -0400, Tom Lane wrote:
> I wrote:
> > Andres Freund <andres@anarazel.de> writes:
> >> Only PM_CHILD_ACTIVE and PM_CHILD_WALSENDER though. We could afford another
> >> MaxLivePostmasterChildren() sized array...
> 
> > Oh, I see what you mean --- one private and one public array.
> > Maybe that makes more sense than what I did, not sure.
> 
> Yeah, that's definitely a better way.  I'll push this after the
> release freeze lifts.

Cool, thanks for exploring.


>  /*
>   * Signal handler to be notified if postmaster dies.
>   */
> @@ -142,7 +152,25 @@ PMSignalShmemInit(void)
>      {
>          /* initialize all flags to zeroes */
>          MemSet(unvolatize(PMSignalData *, PMSignalState), 0, PMSignalShmemSize());
> -        PMSignalState->num_child_flags = MaxLivePostmasterChildren();
> +        num_child_inuse = MaxLivePostmasterChildren();
> +        PMSignalState->num_child_flags = num_child_inuse;
> +
> +        /*
> +         * Also allocate postmaster's private PMChildInUse[] array.  We
> +         * might've already done that in a previous shared-memory creation
> +         * cycle, in which case free the old array to avoid a leak.  (Do it
> +         * like this to support the possibility that MaxLivePostmasterChildren
> +         * changed.)  In a standalone backend, we do not need this.
> +         */
> +        if (PostmasterContext != NULL)
> +        {
> +            if (PMChildInUse)
> +                pfree(PMChildInUse);
> +            PMChildInUse = (bool *)
> +                MemoryContextAllocZero(PostmasterContext,
> +                                       num_child_inuse * sizeof(bool));
> +        }
> +        next_child_inuse = 0;
>      }
>  }

When can PostmasterContext be NULL here, and why can we just continue without
(re-)allocating PMChildInUse?

Greetings,

Andres Freund



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Non-robustness in pmsignal.c
Next
From: Nathan Bossart
Date:
Subject: Re: Adding Support for Copy callback functionality on COPY TO api