Hi Jeff!
Your proposal reminds me of the early resource release mechanism in
Cloudberry. Perhaps this implementation would be useful as an example [1].
In Cloudberry, ExecSquelchNode() tells a subtree that its consumer will
no longer read from it during the current pipeline. This helps prevent
deadlocks in Motion nodes and release working memory earlier.
I think it is important to distinguish two questions here: when a
subtree is no longer needed and which of its resources can be released.
Cloudberry handles the second question on a per-node basis. For example,
the Sort and Material implementations use delayEagerFree, which takes
the REWIND, BACKWARD, and MARK requirements into account. This allows
results to be retained where they are needed for rescanning.
A similar problem was discussed in 2019 [2]. Early shutdown under Limit
destroyed the parallel context, which was subsequently needed for re
scan. The discussion also included a proposal to separate releasing
resources for the current scan from permanently destroying state.
ExecShutdownNode() looks like a suitable place for early memory release,
provided that its handlers preserve any state needed for rescans.
Alternatively, it might be useful to distinguish explicitly between
scan-local resource release and permanent node shutdown.
If this direction sounds useful, I can prepare a follow-up patch on top
of your 0001
[1] Cloudberry, ExecSquelchNode:
https://github.com/apache/cloudberry/blob/cd260a80358475491e6e683c78384c96ad919669/src/backend/executor/execAmi.c#L719
[2] SegFault on 9.6.14:
https://www.postgresql.org/message-id/flat/87ims2amh6.fsf%40jsievers.enova.com
