Обсуждение: Re: [HACKERS] Quorum commit for multiple synchronous replication.
Hello, At Thu, 6 Apr 2017 16:17:31 +0900, Masahiko Sawada <sawada.mshk@gmail.com> wrote in <CAD21AoCcEsjt8t4TWW5oE3g=nu2oMFAiM47YeynpKJMoMdeEPA@mail.gmail.com> > On Thu, Apr 6, 2017 at 10:51 AM, Noah Misch <noah@leadboat.com> wrote: > > On Thu, Apr 06, 2017 at 12:48:56AM +0900, Fujii Masao wrote: > >> On Wed, Apr 5, 2017 at 3:45 PM, Noah Misch <noah@leadboat.com> wrote: > >> > On Mon, Dec 19, 2016 at 09:49:58PM +0900, Fujii Masao wrote: > >> >> Regarding this feature, there are some loose ends. We should work on > >> >> and complete them until the release. > >> >> > >> >> (1) > >> >> Which synchronous replication method, priority or quorum, should be > >> >> chosen when neither FIRST nor ANY is specified in s_s_names? Right now, > >> >> a priority-based sync replication is chosen for keeping backward > >> >> compatibility. However some hackers argued to change this decision > >> >> so that a quorum commit is chosen because they think that most users > >> >> prefer to a quorum. > >> >> > >> >> (2) > >> >> There will be still many source comments and documentations that > >> >> we need to update, for example, in high-availability.sgml. We need to > >> >> check and update them throughly. > >> >> > >> >> (3) > >> >> The priority value is assigned to each standby listed in s_s_names > >> >> even in quorum commit though those priority values are not used at all. > >> >> Users can see those priority values in pg_stat_replication. > >> >> Isn't this confusing? If yes, it might be better to always assign 1 as > >> >> the priority, for example. > >> > > >> > [Action required within three days. This is a generic notification.] > >> > > >> > The above-described topic is currently a PostgreSQL 10 open item. Fujii, > >> > since you committed the patch believed to have created it, you own this open > >> > item. If some other commit is more relevant or if this does not belong as a > >> > v10 open item, please let us know. Otherwise, please observe the policy on > >> > open item ownership[1] and send a status update within three calendar days of > >> > this message. Include a date for your subsequent status update. Testers may > >> > discover new open items at any time, and I want to plan to get them all fixed > >> > well in advance of shipping v10. Consequently, I will appreciate your efforts > >> > toward speedy resolution. Thanks. > >> > > >> > [1] https://www.postgresql.org/message-id/20170404140717.GA2675809%40tornado.leadboat.com > >> > >> Thanks for the notice! > >> > >> Regarding the item (2), Sawada-san told me that he will work on it after > >> this CommitFest finishes. So we would receive the patch for the item from > >> him next week. If there will be no patch even after the end of next week > >> (i.e., April 14th), I will. Let's wait for Sawada-san's action at first. > > > > Sounds reasonable; I will look for your update on 14Apr or earlier. > > > >> The items (1) and (3) are not bugs. So I don't think that they need to be > >> resolved before the beta release. After the feature freeze, many users > >> will try and play with many new features including quorum-based syncrep. > >> Then if many of them complain about (1) and (3), we can change the code > >> at that timing. So we need more time that users can try the feature. > > > > I've moved (1) to a new section for things to revisit during beta. If someone > > feels strongly that the current behavior is Wrong and must change, speak up as > > soon as you reach that conclusion. Absent such arguments, the behavior won't > > change. > > > >> BTW, IMO (3) should be fixed so that pg_stat_replication reports NULL > >> as the priority if quorum-based sync rep is chosen. It's less confusing. > > > > Since you do want (3) to change, please own it like any other open item, > > including the mandatory status updates. > > I agree to report NULL as the priority. I'll send a patch for this as well. In the comment, + /* + * The priority appers NULL as it is not used in quorum-based + * sync replication. + */ appers should be appears. But the comment would be better to be something follows. "The priority value is useless for quorum-based sync replication" or "The priority field is NULL for quorum-based sync replicationsince the value is useless." Or, or, or.. something other. This part, + if (SyncRepConfig && + SyncRepConfig->syncrep_method == SYNC_REP_QUORUM) + nulls[9] = true; + else + values[9] = Int32GetDatum(priority); I looked on how syncrep_method is used in the code and found that it is always used as "== SYNC_REP_PRIORITY" or else. It doesn't matter since currently there's only two alternatives for the variable, but can be problematic when the third alternative comes in. Addition to that, SyncRepConfig is assumed != NULL already in the following part. pg_stat_get_wal_senders()@master > if (priority == 0) > values[10] = CStringGetTextDatum("async"); > else if (list_member_int(sync_standbys, i)) > values[10] = SyncRepConfig->syncrep_method == SYNC_REP_PRIORITY ? > CStringGetTextDatum("sync") : CStringGetTextDatum("quorum"); > else > values[10] = CStringGetTextDatum("potential"); So, it could be as the follows. > if (SyncRepConfig->syncrep_method == SYNC_REP_PRIORITY) > values[9] = Int32GetDatum(priority); > else > nulls[9] = true; regards, -- Kyotaro Horiguchi NTT Open Source Software Center
On Thu, Apr 13, 2017 at 5:17 PM, Kyotaro HORIGUCHI <horiguchi.kyotaro@lab.ntt.co.jp> wrote: > Hello, > > At Thu, 6 Apr 2017 16:17:31 +0900, Masahiko Sawada <sawada.mshk@gmail.com> wrote in <CAD21AoCcEsjt8t4TWW5oE3g=nu2oMFAiM47YeynpKJMoMdeEPA@mail.gmail.com> >> On Thu, Apr 6, 2017 at 10:51 AM, Noah Misch <noah@leadboat.com> wrote: >> > On Thu, Apr 06, 2017 at 12:48:56AM +0900, Fujii Masao wrote: >> >> On Wed, Apr 5, 2017 at 3:45 PM, Noah Misch <noah@leadboat.com> wrote: >> >> > On Mon, Dec 19, 2016 at 09:49:58PM +0900, Fujii Masao wrote: >> >> >> Regarding this feature, there are some loose ends. We should work on >> >> >> and complete them until the release. >> >> >> >> >> >> (1) >> >> >> Which synchronous replication method, priority or quorum, should be >> >> >> chosen when neither FIRST nor ANY is specified in s_s_names? Right now, >> >> >> a priority-based sync replication is chosen for keeping backward >> >> >> compatibility. However some hackers argued to change this decision >> >> >> so that a quorum commit is chosen because they think that most users >> >> >> prefer to a quorum. >> >> >> >> >> >> (2) >> >> >> There will be still many source comments and documentations that >> >> >> we need to update, for example, in high-availability.sgml. We need to >> >> >> check and update them throughly. >> >> >> >> >> >> (3) >> >> >> The priority value is assigned to each standby listed in s_s_names >> >> >> even in quorum commit though those priority values are not used at all. >> >> >> Users can see those priority values in pg_stat_replication. >> >> >> Isn't this confusing? If yes, it might be better to always assign 1 as >> >> >> the priority, for example. >> >> > >> >> > [Action required within three days. This is a generic notification.] >> >> > >> >> > The above-described topic is currently a PostgreSQL 10 open item. Fujii, >> >> > since you committed the patch believed to have created it, you own this open >> >> > item. If some other commit is more relevant or if this does not belong as a >> >> > v10 open item, please let us know. Otherwise, please observe the policy on >> >> > open item ownership[1] and send a status update within three calendar days of >> >> > this message. Include a date for your subsequent status update. Testers may >> >> > discover new open items at any time, and I want to plan to get them all fixed >> >> > well in advance of shipping v10. Consequently, I will appreciate your efforts >> >> > toward speedy resolution. Thanks. >> >> > >> >> > [1] https://www.postgresql.org/message-id/20170404140717.GA2675809%40tornado.leadboat.com >> >> >> >> Thanks for the notice! >> >> >> >> Regarding the item (2), Sawada-san told me that he will work on it after >> >> this CommitFest finishes. So we would receive the patch for the item from >> >> him next week. If there will be no patch even after the end of next week >> >> (i.e., April 14th), I will. Let's wait for Sawada-san's action at first. >> > >> > Sounds reasonable; I will look for your update on 14Apr or earlier. >> > >> >> The items (1) and (3) are not bugs. So I don't think that they need to be >> >> resolved before the beta release. After the feature freeze, many users >> >> will try and play with many new features including quorum-based syncrep. >> >> Then if many of them complain about (1) and (3), we can change the code >> >> at that timing. So we need more time that users can try the feature. >> > >> > I've moved (1) to a new section for things to revisit during beta. If someone >> > feels strongly that the current behavior is Wrong and must change, speak up as >> > soon as you reach that conclusion. Absent such arguments, the behavior won't >> > change. >> > >> >> BTW, IMO (3) should be fixed so that pg_stat_replication reports NULL >> >> as the priority if quorum-based sync rep is chosen. It's less confusing. >> > >> > Since you do want (3) to change, please own it like any other open item, >> > including the mandatory status updates. >> >> I agree to report NULL as the priority. I'll send a patch for this as well. > > > In the comment, Thank you for reviewing! > > + /* > + * The priority appers NULL as it is not used in quorum-based > + * sync replication. > + */ > > appers should be appears. But the comment would be better to be > something follows. Will fix. > > "The priority value is useless for quorum-based sync replication" or > > "The priority field is NULL for quorum-based sync replication > since the value is useless." > > Or, or, or.. something other. Will fix with later part. > > > This part, > > + if (SyncRepConfig && > + SyncRepConfig->syncrep_method == SYNC_REP_QUORUM) > + nulls[9] = true; > + else > + values[9] = Int32GetDatum(priority); > > I looked on how syncrep_method is used in the code and found that > it is always used as "== SYNC_REP_PRIORITY" or else. It doesn't > matter since currently there's only two alternatives for the > variable, but can be problematic when the third alternative comes > in. Agreed. > > Addition to that, SyncRepConfig is assumed != NULL already in the > following part. > > pg_stat_get_wal_senders()@master >> if (priority == 0) >> values[10] = CStringGetTextDatum("async"); >> else if (list_member_int(sync_standbys, i)) >> values[10] = SyncRepConfig->syncrep_method == SYNC_REP_PRIORITY ? >> CStringGetTextDatum("sync") : CStringGetTextDatum("quorum"); >> else >> values[10] = CStringGetTextDatum("potential"); > > So, it could be as the follows. > >> if (SyncRepConfig->syncrep_method == SYNC_REP_PRIORITY) >> values[9] = Int32GetDatum(priority); >> else >> nulls[9] = true; > I guess we cannot do so. Because in the above part, SyncRepConfig is referenced only when synchronous replication is used we can assume SyncRepConfig is not NULL there. Perhaps we put a assertion there. I'll sent updated patch tomorrow. Regards, -- Masahiko Sawada NIPPON TELEGRAPH AND TELEPHONE CORPORATION NTT Open Source Software Center
On Thu, Apr 13, 2017 at 9:23 PM, Masahiko Sawada <sawada.mshk@gmail.com> wrote: > On Thu, Apr 13, 2017 at 5:17 PM, Kyotaro HORIGUCHI > <horiguchi.kyotaro@lab.ntt.co.jp> wrote: >> Hello, >> >> At Thu, 6 Apr 2017 16:17:31 +0900, Masahiko Sawada <sawada.mshk@gmail.com> wrote in <CAD21AoCcEsjt8t4TWW5oE3g=nu2oMFAiM47YeynpKJMoMdeEPA@mail.gmail.com> >>> On Thu, Apr 6, 2017 at 10:51 AM, Noah Misch <noah@leadboat.com> wrote: >>> > On Thu, Apr 06, 2017 at 12:48:56AM +0900, Fujii Masao wrote: >>> >> On Wed, Apr 5, 2017 at 3:45 PM, Noah Misch <noah@leadboat.com> wrote: >>> >> > On Mon, Dec 19, 2016 at 09:49:58PM +0900, Fujii Masao wrote: >>> >> >> Regarding this feature, there are some loose ends. We should work on >>> >> >> and complete them until the release. >>> >> >> >>> >> >> (1) >>> >> >> Which synchronous replication method, priority or quorum, should be >>> >> >> chosen when neither FIRST nor ANY is specified in s_s_names? Right now, >>> >> >> a priority-based sync replication is chosen for keeping backward >>> >> >> compatibility. However some hackers argued to change this decision >>> >> >> so that a quorum commit is chosen because they think that most users >>> >> >> prefer to a quorum. >>> >> >> >>> >> >> (2) >>> >> >> There will be still many source comments and documentations that >>> >> >> we need to update, for example, in high-availability.sgml. We need to >>> >> >> check and update them throughly. >>> >> >> >>> >> >> (3) >>> >> >> The priority value is assigned to each standby listed in s_s_names >>> >> >> even in quorum commit though those priority values are not used at all. >>> >> >> Users can see those priority values in pg_stat_replication. >>> >> >> Isn't this confusing? If yes, it might be better to always assign 1 as >>> >> >> the priority, for example. >>> >> > >>> >> > [Action required within three days. This is a generic notification.] >>> >> > >>> >> > The above-described topic is currently a PostgreSQL 10 open item. Fujii, >>> >> > since you committed the patch believed to have created it, you own this open >>> >> > item. If some other commit is more relevant or if this does not belong as a >>> >> > v10 open item, please let us know. Otherwise, please observe the policy on >>> >> > open item ownership[1] and send a status update within three calendar days of >>> >> > this message. Include a date for your subsequent status update. Testers may >>> >> > discover new open items at any time, and I want to plan to get them all fixed >>> >> > well in advance of shipping v10. Consequently, I will appreciate your efforts >>> >> > toward speedy resolution. Thanks. >>> >> > >>> >> > [1] https://www.postgresql.org/message-id/20170404140717.GA2675809%40tornado.leadboat.com >>> >> >>> >> Thanks for the notice! >>> >> >>> >> Regarding the item (2), Sawada-san told me that he will work on it after >>> >> this CommitFest finishes. So we would receive the patch for the item from >>> >> him next week. If there will be no patch even after the end of next week >>> >> (i.e., April 14th), I will. Let's wait for Sawada-san's action at first. >>> > >>> > Sounds reasonable; I will look for your update on 14Apr or earlier. >>> > >>> >> The items (1) and (3) are not bugs. So I don't think that they need to be >>> >> resolved before the beta release. After the feature freeze, many users >>> >> will try and play with many new features including quorum-based syncrep. >>> >> Then if many of them complain about (1) and (3), we can change the code >>> >> at that timing. So we need more time that users can try the feature. >>> > >>> > I've moved (1) to a new section for things to revisit during beta. If someone >>> > feels strongly that the current behavior is Wrong and must change, speak up as >>> > soon as you reach that conclusion. Absent such arguments, the behavior won't >>> > change. >>> > >>> >> BTW, IMO (3) should be fixed so that pg_stat_replication reports NULL >>> >> as the priority if quorum-based sync rep is chosen. It's less confusing. >>> > >>> > Since you do want (3) to change, please own it like any other open item, >>> > including the mandatory status updates. >>> >>> I agree to report NULL as the priority. I'll send a patch for this as well. >> >> >> In the comment, > > Thank you for reviewing! > >> >> + /* >> + * The priority appers NULL as it is not used in quorum-based >> + * sync replication. >> + */ >> >> appers should be appears. But the comment would be better to be >> something follows. > > Will fix. > >> >> "The priority value is useless for quorum-based sync replication" or >> >> "The priority field is NULL for quorum-based sync replication >> since the value is useless." >> >> Or, or, or.. something other. > > Will fix with later part. > >> >> >> This part, >> >> + if (SyncRepConfig && >> + SyncRepConfig->syncrep_method == SYNC_REP_QUORUM) >> + nulls[9] = true; >> + else >> + values[9] = Int32GetDatum(priority); >> >> I looked on how syncrep_method is used in the code and found that >> it is always used as "== SYNC_REP_PRIORITY" or else. It doesn't >> matter since currently there's only two alternatives for the >> variable, but can be problematic when the third alternative comes >> in. > > Agreed. > >> >> Addition to that, SyncRepConfig is assumed != NULL already in the >> following part. >> >> pg_stat_get_wal_senders()@master >>> if (priority == 0) >>> values[10] = CStringGetTextDatum("async"); >>> else if (list_member_int(sync_standbys, i)) >>> values[10] = SyncRepConfig->syncrep_method == SYNC_REP_PRIORITY ? >>> CStringGetTextDatum("sync") : CStringGetTextDatum("quorum"); >>> else >>> values[10] = CStringGetTextDatum("potential"); >> >> So, it could be as the follows. >> >>> if (SyncRepConfig->syncrep_method == SYNC_REP_PRIORITY) >>> values[9] = Int32GetDatum(priority); >>> else >>> nulls[9] = true; >> > > I guess we cannot do so. Because in the above part, SyncRepConfig is > referenced only when synchronous replication is used we can assume > SyncRepConfig is not NULL there. Perhaps we put a assertion there. > > I'll sent updated patch tomorrow. Thanks! But on second thought, I don't think that reporting NULL as the priority when quorum-based sync replication is used is less confusing. When there is async standby, we report 0 as its priority when synchronous_standby_names is empty or a priority-based sync replication is configured. But with the patch, when a quorum-based one is specified, NULL is reported for that. Isn't this confusing? I'm thinking that it's less confusing to report always 0 as the priority of async standby whatever the setting of synchronous_standby_names is. Thought? If we adopt this idea, in a quorum-based sync replication, I think that the priorities of all the standbys listed in synchronous_standby_names should be 1 instead of NULL. That is, those standbys have the same (highest) priority, and which means that any of them can be chosen as sync standby. Thought? Regards, -- Fujii Masao
On Fri, Apr 14, 2017 at 2:47 AM, Fujii Masao <masao.fujii@gmail.com> wrote: > I'm thinking that it's less confusing to report always 0 as the priority of > async standby whatever the setting of synchronous_standby_names is. > Thought? Or we could have priority being reported to NULL for async standbys as well, the priority number has no meaning for them anyway... > If we adopt this idea, in a quorum-based sync replication, I think that > the priorities of all the standbys listed in synchronous_standby_names > should be 1 instead of NULL. That is, those standbys have the same > (highest) priority, and which means that any of them can be chosen as > sync standby. Thought? Mainly my fault here to suggest that standbys in a quorum set should have a priority set to NULL. My 2c on the matter is that I would be fine with either having the async standbys having a priority of NULL or using a priority of 1 for standbys in a quorum set. Though, honestly, I find that showing a priority number for something where this has no real meaning is even more confusing.. -- Michael
On Fri, Apr 14, 2017 at 9:38 AM, Michael Paquier <michael.paquier@gmail.com> wrote: > On Fri, Apr 14, 2017 at 2:47 AM, Fujii Masao <masao.fujii@gmail.com> wrote: >> I'm thinking that it's less confusing to report always 0 as the priority of >> async standby whatever the setting of synchronous_standby_names is. >> Thought? > > Or we could have priority being reported to NULL for async standbys as > well, the priority number has no meaning for them anyway... I agree to set the same thing (priority or NULL) to all sync standby in a quorum set. As Fujii-san mentioned, I also think that it means all standbys in a quorum set can be chosen equally. But to less confusion for current user I'd not like to change current behavior of the priority of async standby. > >> If we adopt this idea, in a quorum-based sync replication, I think that >> the priorities of all the standbys listed in synchronous_standby_names >> should be 1 instead of NULL. That is, those standbys have the same >> (highest) priority, and which means that any of them can be chosen as >> sync standby. Thought? > > Mainly my fault here to suggest that standbys in a quorum set should > have a priority set to NULL. My 2c on the matter is that I would be > fine with either having the async standbys having a priority of NULL > or using a priority of 1 for standbys in a quorum set. Though, > honestly, I find that showing a priority number for something where > this has no real meaning is even more confusing.. This is just a thought but we can merge sync_priority and sync_state into one column. The sync priority can have meaning only when the standby is considered as a sync standby or a potential standby in priority-based sync replication. For example, we can show something like 'sync:N' as states of the sync standby and 'potential:N' as states of the potential standby in priority-based sync replication, where N means the priority. In quorum-based sync replication it is just 'quorum'. It breaks backward compatibility, though. Regards, -- Masahiko Sawada NIPPON TELEGRAPH AND TELEPHONE CORPORATION NTT Open Source Software Center
At Fri, 14 Apr 2017 10:47:46 +0900, Masahiko Sawada <sawada.mshk@gmail.com> wrote in <CAD21AoD7Scnjrn5m+_eaDEsZnyXpbwGYw7x1sXeipAK=iqBKUQ@mail.gmail.com> > On Fri, Apr 14, 2017 at 9:38 AM, Michael Paquier > <michael.paquier@gmail.com> wrote: > > On Fri, Apr 14, 2017 at 2:47 AM, Fujii Masao <masao.fujii@gmail.com> wrote: > >> I'm thinking that it's less confusing to report always 0 as the priority of > >> async standby whatever the setting of synchronous_standby_names is. > >> Thought? > > > > Or we could have priority being reported to NULL for async standbys as > > well, the priority number has no meaning for them anyway... > > I agree to set the same thing (priority or NULL) to all sync standby > in a quorum set. As Fujii-san mentioned, I also think that it means > all standbys in a quorum set can be chosen equally. But to less > confusion for current user I'd not like to change current behavior of > the priority of async standby. > > > > >> If we adopt this idea, in a quorum-based sync replication, I think that > >> the priorities of all the standbys listed in synchronous_standby_names > >> should be 1 instead of NULL. That is, those standbys have the same > >> (highest) priority, and which means that any of them can be chosen as > >> sync standby. Thought? > > > > Mainly my fault here to suggest that standbys in a quorum set should > > have a priority set to NULL. My 2c on the matter is that I would be > > fine with either having the async standbys having a priority of NULL > > or using a priority of 1 for standbys in a quorum set. Though, > > honestly, I find that showing a priority number for something where > > this has no real meaning is even more confusing.. > > This is just a thought but we can merge sync_priority and sync_state > into one column. The sync priority can have meaning only when the > standby is considered as a sync standby or a potential standby in > priority-based sync replication. For example, we can show something > like 'sync:N' as states of the sync standby and 'potential:N' as > states of the potential standby in priority-based sync replication, > where N means the priority. In quorum-based sync replication it is > just 'quorum'. It breaks backward compatibility, though. I'm not sure how the sync_priority is used, I know sync_state is used to detect the state or soundness of a replication set. Introducing varialbe part wouldn't be welcomed from such people. The current shape of pg_stat_replication is as follows. application_name | sync_priority | sync_state -----------------+---------------+------------ sby1 | 1 | sync sby3 | 2 | potential sby3 | 2 | potential sby2 | 3 | potential Fot this case, the following query will work. SELECT count(*) > 0 FROM pg_stat_replication WHERE sync_state ='sync' Maybe a bit confusing but we can use the field to show how many hosts are required to conform the quorum. For example the case with s_s_names = 'ANY 3 (sby1,sby2,sby3,sby4)'. application_name | sync_priority | sync_state -----------------+---------------+------------ sby1 | 3 | quorum sby4 | 3 | quorum sby2 | 3 | quorum sby3 | 3 | quorum sby3 | 3 | quorum sby5 | 0 | async In this case, we can detect satisfaction of the quorum setup by something like this. SELECT count(*) >= sync_priority FROM pg_stat_replication WHERE sync_state='quorum' GROUP BY sync_priority; But, maybe we should provide a means to detect the standbys really in sync with the master. This doesn't give such information. We could show top N standbys as priority-1 and others as priority-2. (Of course this requires some additional computation.) application_name | flush_location | sync_priority | sync_state -----------------+----------------+---------------+----------- sby1 | 0/700140 | 1 | quorum sby4 | 0/700100 | 1 | quorum sby2 | 0/700080 | 1 | quorum sby3 | 0/6FFF3e | 2 | quorum sby3 | 0/50e345 | 2 | quorum sby5 | 0/700140 | 0 | async In this case, the soundness of the quorum set is checked by the following query. SELECT count(*) > 0 FROM pg_stat_replication WHERE sync_priority > 0; We will find the standbys 'in sync' by the following query. SELECT application_name FROM pg_stat_replication WHERE sync_priority = 1; If the master doesn't have enough standbys. We could show the state as the follows.. perhaps... application_name | flush_location | sync_priority | sync_state -----------------+----------------+---------------+----------- sby1 | 0/700140 | 0 | quorum sby4 | 0/700100 | 0 | quorum sby5 | 0/700140 | 0 | async Or we can use 'quorum-potential' instead of the 'quorum' above. Or, we might be able to keep backward compatibility in a sense. application_name | flush_location | sync_priority | sync_state -----------------+----------------+---------------+----------- sby1 | 0/700140 | 1 | sync sby4 | 0/700100 | 1 | sync sby2 | 0/700080 | 1 | sync sby3 | 0/6FFF3e | 2 | potential sby3 | 0/50e345 | 2 | potential sby5 | 0/700140 | 0 | async In the above discussion, I didn't consider possible future exntensions of this feature. regards, -- Kyotaro Horiguchi NTT Open Source Software Center
On 13 April 2017 at 18:47, Fujii Masao <masao.fujii@gmail.com> wrote: > But on second thought, I don't think that reporting NULL as the priority when > quorum-based sync replication is used is less confusing. When there is async > standby, we report 0 as its priority when synchronous_standby_names is empty > or a priority-based sync replication is configured. But with the patch, when > a quorum-based one is specified, NULL is reported for that. > Isn't this confusing? To me, yes, it is confusing. -- Simon Riggs http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services