On 17/01/17 17:11, Peter Eisentraut wrote: > On 1/15/17 1:48 PM, Petr Jelinek wrote: >> It's meant to decouple the synchronous commit setting for logical >> replication workers from the one set for normal clients. Now that we >> have owners for subscription and subscription runs as that owner, maybe >> we could do that via ALTER USER. > > I was thinking about that as well. > >> However I think the apply should by >> default run with sync commit turned off as the performance benefits are >> important there given that there is one worker that has to replicate in >> serialized manner and the success of replication is not confirmed by >> responding to COMMIT but by reporting LSNs of various replication stages. > > Hmm, I don't think we should ship with an "unsafe" default. Do we have > any measurements of the performance impact? >
I will have to do some for the patch specifically, I only have ones for pglogical/bdr where it's quite significant. The default is not unsafe really, we still report correct flush position to the publisher. The synchronous replication on publisher will still work even if synchronous standby is subscription which itself has sync commit off (that's why the complicated send_feedback()/get_flush_position()) but will have higher latency as flushes don't happen immediately. Cascading should be fine as well even around crashes as logical decoding only picks up flushed WAL. It could be however argued there may be some consistency issues around the crash as other transactions could have already seen data that disappeared after postgres recovery and then reappeared again when the replication caught up again. That might indeed be a show stopper for the default off. -- Petr Jelinek http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
