Re: [HACKERS] logical replication - still unstable after all thesemonths - Mailing list pgsql-hackers

From Peter Eisentraut
Subject Re: [HACKERS] logical replication - still unstable after all thesemonths
Date
Msg-id 3235206e-3cc5-29f4-5104-aa0cb4920512@2ndquadrant.com
Whole thread Raw
In response to Re: [HACKERS] logical replication - still unstable after all thesemonths  (Petr Jelinek <petr.jelinek@2ndquadrant.com>)
Responses Re: [HACKERS] logical replication - still unstable after all thesemonths  (Erik Rijkers <er@xs4all.nl>)
List pgsql-hackers
On 6/4/17 22:38, Petr Jelinek wrote:
> On 03/06/17 16:12, Jeff Janes wrote:
>>
>> On Fri, Jun 2, 2017 at 4:10 PM, Petr Jelinek
>> <petr.jelinek@2ndquadrant.com <mailto:petr.jelinek@2ndquadrant.com>> wrote:
>>
>>
>>     While I was testing something for different thread I noticed that I
>>     manage transactions incorrectly in this patch. Fixed here, I didn't test
>>     it much yet (it takes a while as you know :) ). Not sure if it's related
>>     to the issue you've seen though.
>>
>>
>> This conflicts again with Peter E's recent commit
>> 3c9bc2157a4f465b3c070d1250597568d2dc285f
>>
> 
> Rebased on top of current HEAD.

Committed that, with some further updates of comments to reflect the
changes.

I do like the simplification of the state progression.

Perhaps it could be simplified even further, by eliminating the SYNCDONE
setting in LogicalRepSyncTableStart() and making it go through the apply
loop and end up in process_syncing_tables_for_sync() in all cases.
Which is kind of what the comments at the top of the file suggest would
happen anyway.

-- 
Peter Eisentraut              http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: [HACKERS] Should we standardize on a type for signal handler flags?
Next
From: Mike Palmiotto
Date:
Subject: Re: [HACKERS] [BUGS] BUG #14682: row level security not work with partitioned table