From 943140d572adc94b957d123aa4c35ec88e40e869 Mon Sep 17 00:00:00 2001 From: Tom Lane Date: Mon, 6 Mar 2017 16:50:47 -0500 Subject: [PATCH] Avoid dangling pointer to relation name in RLS code path in DoCopy(). With RLS active, "COPY tab TO ..." failed under -DRELCACHE_FORCE_RELEASE, and would sometimes fail without that, because it used the relation name directly from the relcache as part of the parsetree it's building. That becomes a potentially-dangling pointer as soon as the relcache entry is closed, a bit further down. Typical symptom if the relcache entry chanced to get cleared would be "relation does not exist" error with a garbage relation name, or possibly a core dump; but if you were really truly unlucky, the COPY might copy from the wrong table. Per report from Andrew Dunstan that regression tests fail with -DRELCACHE_FORCE_RELEASE. The core tests now pass for me (but have not tried "make check-world" yet). Discussion: https://postgr.es/m/7b52f900-0579-cda9-ae2e-de5da17090e6@2ndQuadrant.com --- src/backend/commands/copy.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/src/backend/commands/copy.c b/src/backend/commands/copy.c index 5e38edfb70..db6ef78314 100644 --- a/src/backend/commands/copy.c +++ b/src/backend/commands/copy.c @@ -938,7 +938,8 @@ DoCopy(const CopyStmt *stmt, const char *queryString, uint64 *processed) * relation which we have opened and locked. */ from = makeRangeVar(get_namespace_name(RelationGetNamespace(rel)), - RelationGetRelationName(rel), -1); + pstrdup(RelationGetRelationName(rel)), + -1); /* Build query */ select = makeNode(SelectStmt); -- 2.40.0