Hi,
2022-11-09 08:54:54 -0500, Reid Thompson wrote:
> Thanks for looking at this and for the feedback. Responses inline below.
> > > +void
> > > +pgstat_report_backend_allocated_bytes_decrease(uint64
> > > deallocation)
> > > +{
> > > + volatile PgBackendStatus *beentry = MyBEEntry;
> > > +
> > > + /*
> > > + * Cases may occur where shared memory from a previous postmaster
> > > + * invocation still exist. These are cleaned up at startup by
> > > + * dsm_cleanup_using_control_segment. Limit decreasing memory allocated to
> > > + * zero in case no corresponding prior increase exists or decrease has
> > > + * already been accounted for.
> > > + */
> >
> > I don't really follow - postmaster won't ever have a backend status
> > array, so how would they be tracked here?
>
> On startup, a check is made for leftover dsm control segments in the
> DataDir. It appears possible that in certain situations on startup we
> may find and destroy stale segments and thus decrement the allocation
> variable.
>
> I based this off of:
> /ipc/dsm.c
>
> dsm_postmaster_startup:
> 150 dsm_postmaster_startup(PGShmemHeader *shim)
> {
> ...
> 281 }
I don't think we should account for memory allocations done in postmaster in
this patch. They'll otherwise be counted again in each of the forked
backends. As this cleanup happens during postmaster startup, we'll have to
make sure accounting is reset during backend startup.
Greetings,
Andres Freund
