Hi Torsten and thanks for your quick response.
My problem with WAL stream and pg_logical_emit_message is that this will
pollute the wal files resulting in bigger files in which btw are also
archived using archive-command for disaster recovery cases.
I am thinking of an approach that instead of no
As part of the commit operation, Postgres inserts the notification into a
queue. Naturally, that insert is guarded by a lock and that lock is
released only at the very end of the commit operation. This effect gets
much worse if you also configure synchronous replication because commit
finishes only
Hi,
I am measuring a very simple case of pg_notify in an after update trigger.
The trigger is the following:
CREATE
OR REPLACE FUNCTION audit_event() RETURNS TRIGGER AS
$$
BEGIN
PERFORM pg_notify('user', 'hello world');
RETURN NULL;
END;
$$
LANGUAGE plpgsql;
and configured on the
