diff options
author | Tom Lane <tgl@sss.pgh.pa.us> | 2022-11-03 12:01:57 -0400 |
---|---|---|
committer | Tom Lane <tgl@sss.pgh.pa.us> | 2022-11-03 12:01:57 -0400 |
commit | b00f342ea0f01c3964491108dc4428838ffc269e (patch) | |
tree | 155e6bcb55513efb2c8c29f30c282e4af1c939b4 /src/backend/commands/tablecmds.c | |
parent | 50467082c9d44c1cb7d8fc105f65c37338d9a5a0 (diff) | |
download | postgresql-b00f342ea0f01c3964491108dc4428838ffc269e.tar.gz postgresql-b00f342ea0f01c3964491108dc4428838ffc269e.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/commands/tablecmds.c')
0 files changed, 0 insertions, 0 deletions