pgsql: Fix access to no-longer-open relcache entry in logical-rep worke
От | Tom Lane |
---|---|
Тема | pgsql: Fix access to no-longer-open relcache entry in logical-rep worke |
Дата | |
Msg-id | E1lkcs9-0004Bg-6r@gemulon.postgresql.org обсуждение исходный текст |
Список | pgsql-committers |
Fix access to no-longer-open relcache entry in logical-rep worker. If we redirected a replicated tuple operation into a partition child table, and then tried to fire AFTER triggers for that event, the relation cache entry for the child table was already closed. This has no visible ill effects as long as the entry is still there and still valid, but an unluckily-timed cache flush could result in a crash or other misbehavior. To fix, postpone the ExecCleanupTupleRouting call (which is what closes the child table) until after we've fired triggers. This requires a bit of refactoring so that the cleanup function can have access to the necessary state. In HEAD, I took the opportunity to simplify some of worker.c's function APIs based on use of the new ApplyExecutionData struct. However, it doesn't seem safe/practical to back-patch that aspect, at least not without a lot of analysis of possible interactions with a04daa97a. In passing, add an Assert to afterTriggerInvokeEvents to catch such cases. This seems worthwhile because we've grown a number of fairly unstructured ways of calling AfterTriggerEndQuery. Back-patch to v13, where worker.c grew the ability to deal with partitioned target tables. Discussion: https://postgr.es/m/3382681.1621381328@sss.pgh.pa.us Branch ------ master Details ------- https://git.postgresql.org/pg/commitdiff/b39630fd41f25b414d0ea9b30804f4105f2a0aff Modified Files -------------- src/backend/commands/trigger.c | 2 + src/backend/replication/logical/worker.c | 205 +++++++++++++++++++------------ 2 files changed, 129 insertions(+), 78 deletions(-)
В списке pgsql-committers по дате отправления: