PG-2229 Memory leaks once query executed via SPI interface#634
PG-2229 Memory leaks once query executed via SPI interface#634artemgavrilov wants to merge 2 commits intomainfrom
Conversation
59caea0 to
1fd47f9
Compare
Codecov Report❌ Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #634 +/- ##
==========================================
+ Coverage 85.89% 86.08% +0.18%
==========================================
Files 3 3
Lines 1354 1358 +4
Branches 218 219 +1
==========================================
+ Hits 1163 1169 +6
+ Misses 91 90 -1
+ Partials 100 99 -1 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
189046f to
1f47fbc
Compare
| if (nesting_level == 0) | ||
| #else | ||
| if ((nesting_level + plan_nested_level) == 0) | ||
| #endif |
There was a problem hiding this comment.
Here we have to use try/finally because our context created under TopMemoryContext, so it lives forever. In this hook we may have an exception and we want to cleanup memory in this case too.
|
BTW probably safer option will be to create our memory context under |
1f47fbc to
bd420f9
Compare
|
Something went wrong after sync with main branch, I'm on it. |
a7f6a00 to
dab4d33
Compare
| #if PG_VERSION_NUM < 160000 | ||
| PG_TRY(); | ||
| #else | ||
| PG_TRY(1); | ||
| #endif |
There was a problem hiding this comment.
Yes, this is ugly.
| nesting_level--; | ||
| } | ||
| #if PG_VERSION_NUM < 160000 | ||
| PG_CATCH(); | ||
| #else | ||
| PG_CATCH(1); | ||
| #endif | ||
| { | ||
| nesting_level--; | ||
| PG_RE_THROW(); | ||
| } |
There was a problem hiding this comment.
Actually this can be replaced with PG_FINALLY since we dropped PG12 support. Will do it in the following PG.
dab4d33 to
b089d3e
Compare
Attaching memory reset callback to MessageContext is wrong as for background workers that use SPI for query execution such context doesn't exist. There is no other context which lifetime matches our needs, so instead reset our memory context explicitly when we no longer need its data.
As we delete entry from the list we should also free its memory, even if we later reset whole memory context.
b089d3e to
34aa683
Compare
PG-2229
Description
Before attached our memory context cleanup callback to
MessageContext, however this context doesn't exist when query executed via SPI. That caused memory leak. In this PR we explicitly reset our context when we no longer need its data, as there is no other context that matches our lifetime requirements.How to test
I used
worker_spiextension frompostgres/src/test/modules/worker_spiCREATE EXTENSION worker_spi;SELECT worker_spi_launch(1) IS NOT NULL;SELECT pid, query FROM pg_stat_activity;find PID of the process that executes queryWITH deleted AS (DELETE FROM...SELECT pg_log_backend_memory_contexts(<PID>);LOG: level: 2; pg_stat_monitor local store: 8192 total in 1 blocks; 7952 free (0 chunks); 240 used.Without this patch used space will constantly grow over time, while with the patch it will stay constant.
Links