Re: row filtering for logical replication - Mailing list pgsql-hackers

From Alexey Zagarin
Subject Re: row filtering for logical replication
Date
Msg-id c6a2bd52-c5cb-4ca3-aace-ebfe5a330b91@Spark
Whole thread Raw
In response to Re: row filtering for logical replication  (Erik Rijkers <er@xs4all.nl>)
List pgsql-hackers
OK, I'll consider Alexey Kondratov's set of patches as the current
state-of-the-art then. (They still apply.)

Alexey's patch is the rebased version of previous Euler's patch set, with slot type mistake fixed, and adapted to current changes in the master branch. It also has testing improvements. On the other hand, the new patches from Euler include more fixes and the implementation of filtering in COPY (as far as I can tell from code) which addresses my particular pain point with BDR. Hope they'll be joined soon. :)

It turns out this did not work until I added a wait state after the
CREATE SUBSCRIPTION. It always fails without the wait state, and always
works with the wait state.

Do you agree this is a bug?

I'm not sure this is a bug as after the subscription is added (or a new table added to the publication and then the subscription is refreshed), the whole table is synchronized using COPY statement. Depending on size of the table it can take some time. You may want to check srsubstate in pg_subscription_rel instead of just sleep for more reliable implementation.

Alexey

pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: CVE-2017-7484-induced bugs, or, btree cmp functions are not leakproof?
Next
From: Amit Langote
Date:
Subject: Re: remove "msg" parameter from convert_tuples_by_name