On Wed, Oct 22, 2014 at 10:47 PM, Simon Riggs <si...@2ndquadrant.com> wrote: > On 22 October 2014 14:26, Heikki Linnakangas <hlinnakan...@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
I'm OK with this. But the option name "synchronous" seems confusing because pg_receivexlog with sync option can work as async standby. So the better name is needed. > 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() Sorry, I'm going around in the circle. But I'd like to say again, I don't think this is good idea. It prevents asynchronous pg_receivexlog from fsyncing WAL data and sending feedbacks more frequently at all. They are useful, for example, when we want to monitor the write location of asynchronous pg_receivexlog in almost realtime. But if we adopt the idea, since feedback cannot be sent soon in async mode, pg_stat_replication always returns the not-up-to-date location. Regards, -- Fujii Masao -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
