Re: Review of Refactoring code for sync node detection
От | Fujii Masao |
---|---|
Тема | Re: Review of Refactoring code for sync node detection |
Дата | |
Msg-id | CAHGQGwHttfp=H4zwS5nbrBoHMn++zekoNX7a-C8CFNrOf9HMqA@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Review of Refactoring code for sync node detection (Michael Paquier <michael.paquier@gmail.com>) |
Ответы |
Re: Review of Refactoring code for sync node detection
|
Список | pgsql-hackers |
On Mon, Nov 17, 2014 at 2:20 PM, Michael Paquier <michael.paquier@gmail.com> wrote: > On Sun, Nov 16, 2014 at 9:07 PM, Michael Paquier > <michael.paquier@gmail.com> wrote: >> I'll send an updated patch tomorrow. > > Here are updated versions. I divided the patch into two for clarity, > the first one is the actual refactoring patch, renaming > SyncRepGetSynchronousNode to SyncRepGetSynchronousStandby (+alpha, > like updating synchronous to sync in the comments as you mentioned) > such as the namings have no conflicts. > > The second one updates the syncrep code, including WAL sender and WAL > receiver, and its surroundings to use the term "node" instead of > "standby". This brings in the code the idea that a node using > replication APIs is not necessarily a standby, making it more generic. > This can be applied on top of the refactoring patch. If any other > folks (Heikki or Fujii-san?) have comments about this idea feel free. I've not read the patches yet. But while I was reading the code around sync node detection, I thought that it might be good idea to treat the node with priority as special. That is, if we find the active node with the priority 1, we can immediately go out of the sync-node-detection-loop. In many cases we can expect that the sync standby has the priority 1. If yes, treating the priority 1 as special is good way to do, I think. Thought? Regards, -- Fujii Masao
В списке pgsql-hackers по дате отправления: