aboutsummaryrefslogtreecommitdiff
path: root/src/backend/utils/adt/jsonpath_exec.c
diff options
context:
space:
mode:
authorTom Lane <tgl@sss.pgh.pa.us>2019-12-26 15:19:39 -0500
committerTom Lane <tgl@sss.pgh.pa.us>2019-12-26 15:19:39 -0500
commit883c27a1cf9b80d9a1cf13f527ad21024fa1849d (patch)
treec60198e25f695daa67517fc8d1a9211f7166399d /src/backend/utils/adt/jsonpath_exec.c
parent50fa688f303024447fa8b2419a733b551f752769 (diff)
downloadpostgresql-883c27a1cf9b80d9a1cf13f527ad21024fa1849d.tar.gz
postgresql-883c27a1cf9b80d9a1cf13f527ad21024fa1849d.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/jsonpath_exec.c')
0 files changed, 0 insertions, 0 deletions