Re: Fixing order of resowner cleanup in 12, for Windows

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Thomas Munro <thomas(dot)munro(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Fixing order of resowner cleanup in 12, for Windows
Date: 2019-05-06 17:47:16
Message-ID: CA+TgmoY+=fcpgZoXk79Qua6SRUc=CvrXop24dWaGmXddH-J2PA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Mon, May 6, 2019 at 1:32 PM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Robert Haas <robertmhaas(at)gmail(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2019-05-06 17:51:33 Re: Unhappy about API changes in the no-fsm-for-small-rels patch
Previous Message Tom Lane 2019-05-06 17:32:14 Re: Fixing order of resowner cleanup in 12, for Windows