On 04/03/17 06:46, Robert Haas wrote: > On Tue, Feb 28, 2017 at 12:08 PM, Erik Rijkers <e...@xs4all.nl> wrote: >> Would you remind me why synchronous_commit = on was deemed a better default? > > I'm wondering about that, too. If you're trying to do logical > synchronous replication, then maybe there's some argument there, > although even in that case I am not sure it's actually necessary. But > if you're doing asynchronous logical replication, it seems not to make > much sense. I mean, walwriter is going to flush the WAL to disk > within a fraction of a second; why would we wait for that to happen > instead of getting on with replicating the next transaction meanwhile? >
I do agree. And even when doing synchronous replication it should not be problem. We do have code already in place which takes care of reporting correct write/flush position in the situation where upstream does syncrep but downstream has synccommit off. The only anomaly I could think of in terms of having sync commit off on downstream is that some replicated data that were visible will disappear after a crash only to reappear again once replication catches up to where it has been before when doing asynchronous replication. That does not strike me like good enough reason to have by default something like order of magnitude worse performance. So I think we should do it, but it needs to be configurable, my original patch added GUC for it, Peter wanted it to be configurable per subscription. I guess we could add it as another option to the list of WITH (...) options for CREATE and ALTER SUBSCRIPTION. I am not going to write the patch immediately as I'd like to get the initial data copy working correctly first (and I've sunk a lot of time over last couple of weeks into investigation and fixing of various existing bugs in the snapshot builder so it's taking longer than I expected). But the patch for this is trivial anyway. Agreement is the what we need first. -- 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
