sql - PostgreSQL 中数据库触发器的执行上下文

Question

我想使用触发器实现审计日志，触发器在创建、更改和删除数据时被触发以存储一些值。这些触发器应该能够使用进行更改并由 Web 应用程序管理的用户 ID。我对提供这些数据有一些想法，但我似乎并不完全理解触发器的执行上下文是什么。我已通读 PostgreSQL 文档 Overview of Trigger Behavior和其他人，但我的问题似乎没有得到回答。

我想知道的是客户端 session 与一个正在运行的事务和触发器执行之间的交互，以及两者的生命周期以及它们如何相互依赖。根据我的理解，触发器在数据库中独立于创建导致触发器执行的事件的客户端 session 执行。那是对的吗？这意味着触发器及其处理不会影响客户端请求的性能，并且客户端可以随时关闭 session 。如果两者都是独立的，触发器将如何收到有关客户端回滚事务的通知，这在逻辑上意味着根本没有数据发生变化？还是触发器 onyl 在提交事务后执行，因为它们是独立运行的？

或者触发器是否在创建导致触发器执行的事件的客户端 session 中异步执行？这意味着如果客户端出于任何原因关闭它的 session ，触发器也会中止。他们的更改直接绑定(bind)到客户事务，也可以回滚。

我需要了解行为才能知道我想在 another question 中做什么.

感谢您的意见!

Answer 1

From my understanding triggers are executed within the database independently from the client session which created the event which lead to trigger execution. Is that correct? That would mean triggers and their processing wouldn't impact performance of the client request and the client can close the session at any time

不，它们完全依赖于客户端 session ，作为本身与 session 相关的事务的一部分。请参阅 CREATE TRIGGER 中的这段摘录(9.1):

They can be fired either at the end of the statement causing the triggering event, or at the end of the containing transaction; in the latter case they are said to be deferred

来自您的 other question看来您使用的是 8.4，它没有延迟触发器，所以它更简单。触发器总是在语句(触发事件)结束时运行，这意味着在服务器向客户端发送执行确认之前。

紧随其后的 COMMIT 将是一条新指令，并且在触发器完成之前无法执行。