diff options
author | Tom Lane <tgl@sss.pgh.pa.us> | 2019-12-26 15:19:39 -0500 |
---|---|---|
committer | Tom Lane <tgl@sss.pgh.pa.us> | 2019-12-26 15:19:39 -0500 |
commit | ee206cb830eff45179afde06c93643210b52b196 (patch) | |
tree | 0666803a2db5b427e7d93cc9cfd7b318de7b4aa7 /src/backend/utils/adt/tsquery_gist.c | |
parent | 1b2356a2911ca84eefdf5dcb7f574677b8879c80 (diff) | |
download | postgresql-ee206cb830eff45179afde06c93643210b52b196.tar.gz postgresql-ee206cb830eff45179afde06c93643210b52b196.zip |
Fix possible loss of sync between rectypeid and underlying PLpgSQL_type.
When revalidate_rectypeid() acts to update a stale record type OID
in plpgsql's data structures, it fixes the active PLpgSQL_rec struct
as well as the PLpgSQL_type struct it references. However, the latter
is shared across function executions while the former is not. In a
later function execution, the PLpgSQL_rec struct would be reinitialized
by copy_plpgsql_datums and would then contain a stale type OID,
typically leading to "could not open relation with OID NNNN" errors.
revalidate_rectypeid() can easily fix this, fortunately, just by
treating typ->typoid as authoritative.
Per report and diagnosis from Ashutosh Sharma, though this is not his
suggested fix. Back-patch to v11 where this code came in.
Discussion: https://postgr.es/m/CAE9k0Pkd4dZwt9J5pS9xhJFWpUtqs05C9xk_GEwPzYdV=GxwWg@mail.gmail.com
Diffstat (limited to 'src/backend/utils/adt/tsquery_gist.c')
0 files changed, 0 insertions, 0 deletions