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 | 943140d572adc94b957d123aa4c35ec88e40e869 (patch) | |
tree | 52bb5137895d9419d0821fa2e44afdb269baef06 /src/backend/executor/nodeBitmapIndexscan.c | |
parent | 68f7b91e509d9ac95a376805df22bc9b51e71255 (diff) | |
download | postgresql-943140d572adc94b957d123aa4c35ec88e40e869.tar.gz postgresql-943140d572adc94b957d123aa4c35ec88e40e869.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/executor/nodeBitmapIndexscan.c')
0 files changed, 0 insertions, 0 deletions