Re: pg_receivexlog --status-interval add fsync feedback
От | Simon Riggs |
---|---|
Тема | Re: pg_receivexlog --status-interval add fsync feedback |
Дата | |
Msg-id | CA+U5nMLckP_=0iVU6kfpBxMb00-LxSeDGYiCYyxTfaPjzAo5yg@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: pg_receivexlog --status-interval add fsync feedback (Heikki Linnakangas <hlinnakangas@vmware.com>) |
Ответы |
Re: pg_receivexlog --status-interval add fsync feedback
|
Список | pgsql-hackers |
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
В списке pgsql-hackers по дате отправления: