Andres Freund writes:
> When can PostmasterContext be NULL here, and why can we just continue without
> (re-)allocating PMChildInUse?
We'd only get into the !found stanza in a postmaster or a
standalone backend. A standalone backend isn't ever going to call
AssignPostmasterChildSlot or ReleasePo
Hi,
On 2022-10-08 13:15:07 -0400, Tom Lane wrote:
> I wrote:
> > Andres Freund 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 th
I wrote:
> Andres Freund 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 defi
Andres Freund writes:
> On 2022-10-07 20:35:58 -0400, Tom Lane wrote:
>> Andres Freund writes:
>>> Why are we even tracking PM_CHILD_UNUSED / PM_CHILD_ASSIGNED in shared
>>> memory?
>> Because those flags are set by the child processes too, cf
>> MarkPostmasterChildActive and MarkPostmasterChil
Hi,
On 2022-10-07 20:35:58 -0400, Tom Lane wrote:
> Andres Freund writes:
> > Why are we even tracking PM_CHILD_UNUSED / PM_CHILD_ASSIGNED in shared
> > memory?
>
> Because those flags are set by the child processes too, cf
> MarkPostmasterChildActive and MarkPostmasterChildInactive.
Only PM_C
Andres Freund writes:
> Why are we even tracking PM_CHILD_UNUSED / PM_CHILD_ASSIGNED in shared memory?
Because those flags are set by the child processes too, cf
MarkPostmasterChildActive and MarkPostmasterChildInactive.
> Are you thinking these should be backpatched?
I am, but I'm not inclined
Hi,
On 2022-10-07 19:57:35 -0400, Tom Lane wrote:
> As I mentioned in another thread, I came across a reproducible
> situation in which a memory clobber in a child backend crashes
> the postmaster too, at least on FreeBSD/arm64. Needless to say,
> this is Not Cool.
Ugh.
> I've now traced down
As I mentioned in another thread, I came across a reproducible
situation in which a memory clobber in a child backend crashes
the postmaster too, at least on FreeBSD/arm64. Needless to say,
this is Not Cool. I've now traced down what is happening,
and it's this:
1. Careless coding in aset.c caus
