aboutsummaryrefslogtreecommitdiff
path: root/src
diff options
context:
space:
mode:
authorTom Lane <tgl@sss.pgh.pa.us>2024-07-01 12:21:07 -0400
committerTom Lane <tgl@sss.pgh.pa.us>2024-07-01 12:21:07 -0400
commit8565fb6fbb6908b6af0ad2035820cb7578f9bcb8 (patch)
treef1d56efedd0508f1e97ed1423e6cf6e0bdeb86b8 /src
parent79567599cd2166867fd0057363800d0604f4fc64 (diff)
downloadpostgresql-8565fb6fbb6908b6af0ad2035820cb7578f9bcb8.tar.gz
postgresql-8565fb6fbb6908b6af0ad2035820cb7578f9bcb8.zip
Preserve CurrentMemoryContext across notify and sinval interrupts.
ProcessIncomingNotify is called from the main processing loop that normally runs in MessageContext. That outer-loop code assumes that whatever it allocates will be cleaned up when we're done processing the current client message --- but if we service a notify interrupt, then whatever gets allocated before the next switch into MessageContext will be permanently leaked in TopMemoryContext, because CommitTransactionCommand sets CurrentMemoryContext to TopMemoryContext. There are observable leaks associated with (at least) encoding conversion of incoming queries and parameters attached to Bind messages. sinval catchup interrupts have a similar problem. There might be others, but I've not identified any other clear cases. To fix, take care to save and restore CurrentMemoryContext across the Start/CommitTransactionCommand calls in these functions. Per bug #18512 from wizardbrony. Commit to back branches only; in HEAD, this was dealt with by the riskier but more thoroughgoing approach in commit 1afe31f03. Discussion: https://postgr.es/m/3478884.1718656625@sss.pgh.pa.us
Diffstat (limited to 'src')
-rw-r--r--src/backend/commands/async.c11
-rw-r--r--src/backend/storage/ipc/sinval.c7
2 files changed, 17 insertions, 1 deletions
diff --git a/src/backend/commands/async.c b/src/backend/commands/async.c
index d8f1408e9e9..10ef8f18546 100644
--- a/src/backend/commands/async.c
+++ b/src/backend/commands/async.c
@@ -2103,6 +2103,8 @@ asyncQueueAdvanceTail(void)
static void
ProcessIncomingNotify(void)
{
+ MemoryContext oldcontext;
+
/* We *must* reset the flag */
notifyInterruptPending = false;
@@ -2117,14 +2119,21 @@ ProcessIncomingNotify(void)
/*
* We must run asyncQueueReadAllNotifications inside a transaction, else
- * bad things happen if it gets an error.
+ * bad things happen if it gets an error. However, we need to preserve
+ * the caller's memory context (typically MessageContext).
*/
+ oldcontext = CurrentMemoryContext;
+
StartTransactionCommand();
asyncQueueReadAllNotifications();
CommitTransactionCommand();
+ /* Caller's context had better not have been transaction-local */
+ Assert(MemoryContextIsValid(oldcontext));
+ MemoryContextSwitchTo(oldcontext);
+
/*
* Must flush the notify messages to ensure frontend gets them promptly.
*/
diff --git a/src/backend/storage/ipc/sinval.c b/src/backend/storage/ipc/sinval.c
index a457c876c2b..b43d49568ec 100644
--- a/src/backend/storage/ipc/sinval.c
+++ b/src/backend/storage/ipc/sinval.c
@@ -17,6 +17,7 @@
#include "access/xact.h"
#include "commands/async.h"
#include "miscadmin.h"
+#include "nodes/memnodes.h"
#include "storage/ipc.h"
#include "storage/proc.h"
#include "storage/sinvaladt.h"
@@ -184,6 +185,7 @@ ProcessCatchupInterrupt(void)
* can just call AcceptInvalidationMessages() to do this. If we
* aren't, we start and immediately end a transaction; the call to
* AcceptInvalidationMessages() happens down inside transaction start.
+ * Be sure to preserve caller's memory context when we do that.
*
* It is awfully tempting to just call AcceptInvalidationMessages()
* without the rest of the xact start/stop overhead, and I think that
@@ -197,9 +199,14 @@ ProcessCatchupInterrupt(void)
}
else
{
+ MemoryContext oldcontext = CurrentMemoryContext;
+
elog(DEBUG4, "ProcessCatchupEvent outside transaction");
StartTransactionCommand();
CommitTransactionCommand();
+ /* Caller's context had better not have been transaction-local */
+ Assert(MemoryContextIsValid(oldcontext));
+ MemoryContextSwitchTo(oldcontext);
}
}
}