On 22 October 2014 14:26, Heikki Linnakangas <hlinnakangas@vmware.com> wrote:
> We seem to be going in circles. You suggested having two options,
> --feedback, and --fsync, which is almost exactly what Furuya posted
> originally. I objected to that, because I think that user interface is too
> complicated. Instead, I suggested having just a single option called
> --synchronous, or even better, have no option at all and have the server
> tell the client if it's participating in synchronous replication, and have
> pg_receivexlog automatically fsync when it is, and not otherwise [1]. That
> way you don't need to expose any new options to the user. What did you think
> of that idea?
Sorry, if we're going in circles.
Yes, I like the idea.
The master setting of synchronous_standby_names defines which
standbys/rep clients will have their feedback used to release waiting
COMMITs. That uses application_name, which is set at the replication
client connection. (That has a default value, but lets assume the user
sets this). So when a replication client connects, the WALSender knows
its priority, as defined in sync_standby_names.
I guess we can have WALSender send a protocol message to the client
every time the sync priority changes (as a result of a changed value
of sync_standby_names). Which is the function SyncRepInitConfig()
-- Simon Riggs http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training & Services