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

From Erik Rijkers
Subject Re: row filtering for logical replication
Date
Msg-id 9f25bd90d9f959f364efe79d92468682@xs4all.nl
Whole thread Raw
In response to Re: row filtering for logical replication  (Euler Taveira <euler@timbira.com.br>)
Responses Re: row filtering for logical replication
List pgsql-hackers
On 2019-09-03 05:32, Euler Taveira wrote:
> Em ter, 3 de set de 2019 às 00:16, Alexey Zagarin <zagarin@gmail.com> 
> escreveu:
>> 
>> There are complaints in the log (both pub and sub) like:
>> ERROR: trying to store a heap tuple into wrong type of slot
>> 
>> I have no idea what causes that.
>> 
>> Yeah, I've seen that too. It was fixed by Alexey Kondratov, in line 
>> 955 of 0005-Row-filtering-for-logical-replication.patch it should be 
>> &TTSOpsHeapTuple instead of &TTSOpsVirtual.
>> 
> Ops... exact. That was an oversight while poking with different types 
> of slots.

OK, I'll consider Alexey Kondratov's set of patches as the current 
state-of-the-art then.  (They still apply.)

I found a problem where I'm not sure it's a bug:

The attached bash script does a test by setting up pgbench tables on 
both master and replica, and then sets up logical replication for a 
slice of pgbench_accounts. Then it does a short pgbench run, and loops 
until the results become identical(ok) (or breaks out after a certain 
time (NOK=not ok)).

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?


thanks (also to both Alexeys :))


Erik Rijkers


PS
by the way, this script won't run as-is on other machines; it has stuff 
particular to my local setup.



Attachment

pgsql-hackers by date:

Previous
From: Thomas Munro
Date:
Subject: Re: SIGQUIT on archiver child processes maybe not such a hot idea?
Next
From: Michael Paquier
Date:
Subject: Re: [HACKERS] CLUSTER command progress monitor