postgres.git / summary / log / commit / refs

commit    420d9ec0aebb0cd8d3198d25d6acaf07b0a576b9
Author:   Tom Lane <tgl@sss.pgh.pa.us>
Date:     Mon Mar 06 21:50:47 2017 +0000

    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 96ed21aae93..f93d4ed7cfc 100644
--- a/src/backend/commands/copy.c
+++ b/src/backend/commands/copy.c
@@ -940,7 +940,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);


[parent: 807df31d19e7]