Hello, At Wed, 27 Apr 2016 18:05:26 -0400, Tom Lane <t...@sss.pgh.pa.us> wrote in <3167.1461794...@sss.pgh.pa.us> > Kyotaro HORIGUCHI <horiguchi.kyot...@lab.ntt.co.jp> writes: > > Sorry, I have attached an empty patch. This is another one that should > > be with content. > > I pushed this after whacking it around some, and cleaning up some > sort-of-related problems in the syncrep parser/lexer.
Thank you for pushing this (with improvements) and improvements of synchronous_standby_names. I agree to the discussion that standby names should have restriction not to break possible extension to be happen near future. > There remains a point that I'm not very happy about, which is the code > in check_synchronous_standby_names to emit a WARNING if the num_sync > setting is too large. That's a pretty bad compromise: we should either > decide that the case is legal or that it is not. If it's legal, people > who are correctly using the case will not thank us for logging a WARNING > every single time the postmaster gets a SIGHUP (and those who aren't using > it correctly will have their systems freezing up, warning or no warning). > If it's not legal, we should make it an error not a warning. This specification makes the code a bit complex and makes the document a bit less understandable. It seems to me somewhat suspicious that allowing duplcate (potentially synchronous) walrecivers is so useful as to justify such disadvantages. In spite of this, my inclination is also the same as the following:p rather than making the behavior consistent and clear. > My inclination is to just rip out the warning. Is there anyone object to removing the warining? > But I wonder whether the > desire to have one doesn't imply that the semantics are poorly chosen > and should be revisited. We already have abandoned a bit of backward compatibility in this feature. regards, -- Kyotaro Horiguchi NTT Open Source Software Center -- Sent via pgsql-hackers mailing list (firstname.lastname@example.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers