On Mon, May 6, 2019 at 1:32 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Robert Haas <robertmhaas@gmail.com> writes:
> > I have a thought about this. It seems to me that when it comes to
> > backend-private memory, we release it even later: aborting the
> > transaction does nothing, and we do it only later when we clean up the
> > transaction. So I wonder whether we're going to find that we actually
> > want to postpone reclaiming dynamic shared memory for even longer than
> > this change would do. But in general, I think we've already
> > established the principle that releasing memory needs to happen last,
> > because every other resource that you might be using is tracked using
> > data structures that are, uh, stored in memory. Therefore I suspect
> > that this change is going in the right direction.
>
> Hmm. That argument suggests that DSM cleanup shouldn't be part of
> resowner cleanup at all, but should be handled as a bespoke, late
> step in transaction cleanup, as memory-context release is.
>
> Not sure if that's going too far or not. It would definitely be a big
> change in environment for DSM-cleanup hooks.
Right. That's why I favor applying the change to move DSM cleanup to
the end for now, and seeing how that goes. It could be that we'll
eventually discover that doing it before all of the AtEOXact_BLAH
functions have had a short at doing their thing is still too early,
but the only concrete problem that we know about right now can be
solved by this much-less-invasive change.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company