aboutsummaryrefslogtreecommitdiff
path: root/src/backend/utils/adt/json.c
diff options
context:
space:
mode:
authorTom Lane <tgl@sss.pgh.pa.us>2022-11-03 12:01:57 -0400
committerTom Lane <tgl@sss.pgh.pa.us>2022-11-03 12:02:14 -0400
commitdea83493800563d9f78b68bf9717988dd272c7c9 (patch)
tree1c40739c57838085a6e4e3b6cee1049edb21337c /src/backend/utils/adt/json.c
parent5fca91025e05f803140831953c09a36f08efcef5 (diff)
downloadpostgresql-dea83493800563d9f78b68bf9717988dd272c7c9.tar.gz
postgresql-dea83493800563d9f78b68bf9717988dd272c7c9.zip
Avoid crash after function syntax error in a replication worker.
If a syntax error occurred in a SQL-language or PL/pgSQL-language CREATE FUNCTION or DO command executed in a logical replication worker, we'd suffer a null pointer dereference or assertion failure. That seems like a rather contrived case, but nonetheless worth fixing. The cause is that function_parse_error_transpose assumes it must be executing within the context of a Portal, but logical/worker.c doesn't create a Portal since it's not running the standard executor. We can just back off the hard Assert check and make it fail gracefully if there's not an ActivePortal. (I have a feeling that the aggressive check here was my fault originally, probably because I wasn't sure if the case would always hold and wanted to find out. Well, now we know.) The hazard seems to exist in all branches that have logical replication, so back-patch to v10. Maxim Orlov, Anton Melnikov, Masahiko Sawada, Tom Lane Discussion: https://postgr.es/m/b570c367-ba38-95f3-f62d-5f59b9808226@inbox.ru Discussion: https://postgr.es/m/adf0452f-8c6b-7def-d35e-ab516c80088e@inbox.ru
Diffstat (limited to 'src/backend/utils/adt/json.c')
0 files changed, 0 insertions, 0 deletions