On 06/01/17 21:26, Peter Eisentraut wrote: > 0005-Add-separate-synchronous-commit-control-for-logical--v16.patch.gz > > This looks a little bit hackish. I'm not sure how this would behave > properly when either synchronous_commit or > logical_replication_synchronous_commit is changed at run time with a reload. >
Yes, I said in the initial email that this is meant for discussion and not as final implementation. And certainly it's not required for initial commit. Perhaps I should have started separate thread for this part. > I'm thinking maybe this and perhaps some other WAL receiver settings > should be properties of a subscription, like ALTER SUBSCRIPTION ... > SET/RESET. > True, but we still need the GUC defaults. > Actually, maybe I'm a bit confused what this is supposed to achieve. > synchronous_commit has both a local and a remote meaning. What behavior > are the various combinations of physical and logical replication > supposed to accomplish? > 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. 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. Perhaps the logical_replication_synchronous_commit should only be boolean that would translate to 'off' and 'local' for the real synchronous_commit. -- 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