From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
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:32:14 |
Message-ID: | 25016.1557163934@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2019-05-06 17:47:16 | Re: Fixing order of resowner cleanup in 12, for Windows |
Previous Message | Jonathan S. Katz | 2019-05-06 17:29:35 | Re: First-draft release notes for back branches are up |