aboutsummaryrefslogtreecommitdiff
path: root/src/backend/access/gist/gistget.c
diff options
context:
space:
mode:
authorTom Lane <tgl@sss.pgh.pa.us>2017-03-06 16:50:47 -0500
committerTom Lane <tgl@sss.pgh.pa.us>2017-03-06 16:50:47 -0500
commit420d9ec0aebb0cd8d3198d25d6acaf07b0a576b9 (patch)
treec6f98bea14cfe8d17ba93b7a68aa3fad4cfd17c8 /src/backend/access/gist/gistget.c
parent807df31d19e7014df1d3621292589d3653f614f2 (diff)
downloadpostgresql-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/backend/access/gist/gistget.c')
0 files changed, 0 insertions, 0 deletions