Thread: BUG #15293: Stored Procedure Triggered by Logical Replication isUnable to use Notification Events

The following bug has been logged on the website:

Bug reference:      15293
Logged by:          Michael Powers
Email address:      michael.paul.powers@gmail.com
PostgreSQL version: 10.4
Operating system:   Ubuntu 18.04 Desktop x64 - Linux 4.15.0-29-generic
Description:

When using logical replication a stored procedure executed on the replica is
unable to use NOTIFY to send messages to other listeners. The stored
procedure does execute as expected but the pg_notify() doesn't appear to
have any effect. If an insert is run on the replica side the trigger
executes the stored procedure as expected and the NOTIFY correctly notifies
listeners.

Steps to Reproduce:
Set up Master:
CREATE TABLE test (id SERIAL PRIMARY KEY, msg TEXT NOT NULL);
CREATE PUBLICATION testpub FOR TABLE test;

Set up Replica:
CREATE TABLE test (id SERIAL PRIMARY KEY, msg TEXT NOT NULL);
CREATE SUBSCRIPTION testsub CONNECTION 'host=192.168.0.136 user=test
password=test' PUBLICATION testpub;
CREATE OR REPLACE FUNCTION notify_channel() RETURNS trigger AS $$
BEGIN
    RAISE LOG 'Notify Triggered';
    PERFORM pg_notify('testchannel', 'Testing');
    RETURN NEW;
END;
$$ LANGUAGE 'plpgsql';
DROP TRIGGER queue_insert ON TEST;
CREATE TRIGGER queue_insert AFTER INSERT ON test FOR EACH ROW EXECUTE
PROCEDURE notify_channel();
ALTER TABLE test ENABLE ALWAYS TRIGGER queue_insert;
LISTEN testchannel;

Run the following insert on the master:
INSERT INTO test (msg) VALUES ('test');

In postgresql-10-main.log I get the following:
2018-07-24 07:45:15.705 EDT [6701] LOG:  00000: Notify Triggered
2018-07-24 07:45:15.705 EDT [6701] CONTEXT:  PL/pgSQL function
notify_channel() line 3 at RAISE
2018-07-24 07:45:15.705 EDT [6701] LOCATION:  exec_stmt_raise,
pl_exec.c:3337

But no listeners receive the message. However if an insert is run directly
on the replica:
# INSERT INTO test VALUES (99999, 'test');
INSERT 0 1
Asynchronous notification "testchannel" with payload "Testing" received from
server process with PID 6701.
Asynchronous notification "testchannel" with payload "Testing" received from
server process with PID 6701.
Asynchronous notification "testchannel" with payload "Testing" received from
server process with PID 6701.
Asynchronous notification "testchannel" with payload "Testing" received from
server process with PID 6701.
Asynchronous notification "testchannel" with payload "Testing" received from
server process with PID 6701.
Asynchronous notification "testchannel" with payload "Testing" received from
server process with PID 9992.

Backed up notifications are received for previous NOTIFY's.

Hello
Thank you for report

I checked this bug and found reason: we do not notify backends about new events by call ProcessCompletedNotifies from
logicalworker.
 
New notify from regular backend does call ProcessCompletedNotifies: send signal to all listen backends and found new
eventsfor youself.
 
But i am not sure where is correct place for call ProcessCompletedNotifies in logical worker
src/backend/replication/logical/worker.cand i can not provide patch.
 

regards, Sergei

Hi,

On 2018-07-24 16:19:45 +0300, Sergei Kornilov wrote:
> I checked this bug and found reason: we do not notify backends about new events by call ProcessCompletedNotifies from
logicalworker.
 
> New notify from regular backend does call ProcessCompletedNotifies: send signal to all listen backends and found new
eventsfor youself.
 
> But i am not sure where is correct place for call ProcessCompletedNotifies in logical worker
src/backend/replication/logical/worker.cand i can not provide patch.
 

Peter, Petr, this is the second report of this issue. Anything?

Greetings,

Andres Freund

Hello
in fact, I've already tried to build fix. Adding ProcessCompletedNotifies to apply_handle_commit fixed this issue and i
thinkthis is right place. In src/backend/tcop/postgres.c we call ProcessCompletedNotifies similar way after commit.
Thischange pass make check-world.
 
So i attach my two line patch.

regards, Sergei