unexpected behavior with pglogical -- bug?

From: Torsten Förtsch <tfoertsch123(at)gmail(dot)com>
To: PostgreSQL mailing lists <pgsql-general(at)postgresql(dot)org>
Subject: unexpected behavior with pglogical -- bug?
Date: 2019-06-16 20:45:41
Message-ID: CAKkG4_n6LG2N_1EYq3n8swCosWo3H85AM9xWfTxC7626qVX8+Q@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

Hi,

out of curiosity I created the following setup, all with 9.6 and pglogical.

D1 is configured as provider with a replication set that contains only 1
table. Only inserts are replicated.

D2 is configured as subscriber for that replication set. Replication works,
all inserts on D2 arrive also on D2.

Now, I add the following always firing trigger to the table:

CREATE OR REPLACE FUNCTION notify.trgfn () RETURNS trigger AS $def$
BEGIN
PERFORM pg_notify(NEW.channel, NEW.msg);
RETURN NULL;
END
$def$ LANGUAGE plpgsql;

CREATE TRIGGER trg BEFORE INSERT ON notify.notify
FOR EACH ROW
EXECUTE PROCEDURE notify.trgfn();

ALTER TABLE notify.notify ENABLE ALWAYS TRIGGER trg;

As you can see, the trigger function should prevent the actual insert and
only call pg_notify(). In principle this works but there is a catch.
Notifications generated this way are only delivered after another
notification genuinely generated on the subscriber node. The channel of
this notification does not matter. If I replace PERFORM pg_notify() by RAISE
NOTICE I see the message immediately in the log.

First I thought this is related to session_replication_role=replica. So, I
tried the direct insert on D2 with this setting using psql. The
notification was fired immediately. Also, whether the trigger prevents or
allows the actual insert does not matter. I tried to create the trigger
function as SECURITY DEFINER and with a specific search_path. That didn't
help either.

By now I am thinking there must be something missing in pglogical.

Thanks,
Torsten

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Alvaro Herrera 2019-06-16 21:00:59 Re: checkpoints taking much longer than expected
Previous Message Stephen Frost 2019-06-16 20:37:49 Re: checkpoints taking much longer than expected