diff options
| author | Tom Lane <tgl@sss.pgh.pa.us> | 2017-03-06 16:50:47 -0500 |
|---|---|---|
| committer | Tom Lane <tgl@sss.pgh.pa.us> | 2017-03-06 16:50:47 -0500 |
| commit | 420d9ec0aebb0cd8d3198d25d6acaf07b0a576b9 (patch) | |
| tree | c6f98bea14cfe8d17ba93b7a68aa3fad4cfd17c8 /src | |
| parent | 807df31d19e7014df1d3621292589d3653f614f2 (diff) | |
| download | postgresql-420d9ec0aebb0cd8d3198d25d6acaf07b0a576b9.tar.gz postgresql-420d9ec0aebb0cd8d3198d25d6acaf07b0a576b9.zip | |
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
Diffstat (limited to 'src')
| -rw-r--r-- | src/backend/commands/copy.c | 3 |
1 files changed, 2 insertions, 1 deletions
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); |