Re: [HACKERS] Support for N synchronous standby servers - take 2

Kyotaro HORIGUCHI writes: > At Wed, 27 Apr 2016 18:05:26 -0400, Tom Lane wrote in > <3167.1461794...@sss.pgh.pa.us> >> My inclination is to just rip out the warning. > Is there anyone object to removing the warining? Hearing no objections, done. regards, tom lane --

Re: [HACKERS] Support for N synchronous standby servers - take 2

Hello, At Wed, 27 Apr 2016 18:05:26 -0400, Tom Lane wrote in <3167.1461794...@sss.pgh.pa.us> > Kyotaro HORIGUCHI 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-

Re: [HACKERS] Support for N synchronous standby servers - take 2

Kyotaro HORIGUCHI 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. There remains a point that I'm not very happy about, which

Re: [HACKERS] Support for N synchronous standby servers - take 2

Kyotaro HORIGUCHI writes: > Sorry, I have attached an empty patch. This is another one that should > be with content. I started to review this, and in passing came across this gem in syncrep_scanner.l: /* * flex emits a yy_fatal_error() function that it calls in response to * critical error

Re: [HACKERS] Support for N synchronous standby servers - take 2

On Wed, Apr 27, 2016 at 10:14 AM, Kyotaro HORIGUCHI wrote: > I just added a comment in the v9. Sorry, I have attached an empty patch. This is another one that should be with content. regards, -- Kyotaro Horiguchi NTT Open Source Software Center fix_sync_rep_update_conf_v9.patch Description:

Re: [HACKERS] Support for N synchronous standby servers - take 2

Hello, At Tue, 26 Apr 2016 09:57:50 +0530, Amit Kapila wrote in > > > > Amit Kapila writes: > > > > > The main point for this improvement is that the handling for guc > > s_s_names > > > > > is not similar to what we do for other somewhat similar guc's and > > which > > > > > causes in-efficie

Re: [HACKERS] Support for N synchronous standby servers - take 2

On Tue, Apr 26, 2016 at 9:15 AM, Kyotaro HORIGUCHI < horiguchi.kyot...@lab.ntt.co.jp> wrote: > Hello, attached is the new version v8. > > At Tue, 26 Apr 2016 11:02:25 +0900 (Tokyo Standard Time), Kyotaro > HORIGUCHI wrote in < > 20160426.110225.35506931.horiguchi.kyot...@lab.ntt.co.jp> > > At Sat

Re: [HACKERS] Support for N synchronous standby servers - take 2

Hello, attached is the new version v8. At Tue, 26 Apr 2016 11:02:25 +0900 (Tokyo Standard Time), Kyotaro HORIGUCHI wrote in <20160426.110225.35506931.horiguchi.kyot...@lab.ntt.co.jp> > At Sat, 23 Apr 2016 10:12:03 -0400, Tom Lane wrote in > <476.1461420...@sss.pgh.pa.us> > > Amit Kapila writ

Re: [HACKERS] Support for N synchronous standby servers - take 2

At Sat, 23 Apr 2016 10:12:03 -0400, Tom Lane wrote in <476.1461420...@sss.pgh.pa.us> > Amit Kapila writes: > > The main point for this improvement is that the handling for guc s_s_names > > is not similar to what we do for other somewhat similar guc's and which > > causes in-efficiency in non-ho

Re: [HACKERS] Support for N synchronous standby servers - take 2

Amit Kapila writes: > The main point for this improvement is that the handling for guc s_s_names > is not similar to what we do for other somewhat similar guc's and which > causes in-efficiency in non-hot code path (less used code). This is not about efficiency, this is about correctness. The pr

Re: [HACKERS] Support for N synchronous standby servers - take 2

On Sat, Apr 23, 2016 at 5:20 PM, Michael Paquier wrote: > > On Sat, Apr 23, 2016 at 7:44 PM, Amit Kapila wrote: > > On Wed, Apr 20, 2016 at 12:46 PM, Kyotaro HORIGUCHI > > wrote: > >> > >> > >> assign_s_s_names causes SEGV when it is called without calling > >> check_s_s_names. I think that's no

Re: [HACKERS] Support for N synchronous standby servers - take 2

On Sat, Apr 23, 2016 at 7:44 PM, Amit Kapila wrote: > On Wed, Apr 20, 2016 at 12:46 PM, Kyotaro HORIGUCHI > wrote: >> >> >> assign_s_s_names causes SEGV when it is called without calling >> check_s_s_names. I think that's not the case for this varialbe >> because it is unresettable amid a session

Re: [HACKERS] Support for N synchronous standby servers - take 2

On Wed, Apr 20, 2016 at 12:46 PM, Kyotaro HORIGUCHI < horiguchi.kyot...@lab.ntt.co.jp> wrote: > > > assign_s_s_names causes SEGV when it is called without calling > check_s_s_names. I think that's not the case for this varialbe > because it is unresettable amid a session. It is very uneasy for > me

Re: [HACKERS] Support for N synchronous standby servers - take 2

At Wed, 20 Apr 2016 11:51:09 +0900, Masahiko Sawada wrote in > On Mon, Apr 18, 2016 at 2:15 PM, Kyotaro HORIGUCHI > wrote: > > At Fri, 15 Apr 2016 17:36:57 +0900, Masahiko Sawada > > wrote in > > > >> How about if check_hook just parses parameter in > >> CurrentMemoryContext(i.g., T_AllocSe

Re: [HACKERS] Support for N synchronous standby servers - take 2

On Mon, Apr 18, 2016 at 2:15 PM, Kyotaro HORIGUCHI wrote: > At Fri, 15 Apr 2016 17:36:57 +0900, Masahiko Sawada > wrote in >> >> How about if we do all the parsing stuff in temporary context and then >> >> copy >> >> the results using TopMemoryContext? I don't think it will be a leak in >> >>

Re: [HACKERS] Support for N synchronous standby servers - take 2

At Fri, 15 Apr 2016 17:36:57 +0900, Masahiko Sawada wrote in > >> How about if we do all the parsing stuff in temporary context and then copy > >> the results using TopMemoryContext? I don't think it will be a leak in > >> TopMemoryContext, because next time we try to check/assign s_s_names, it

Re: [HACKERS] Support for N synchronous standby servers - take 2

At Sat, 16 Apr 2016 12:50:30 +0530, Amit Kapila wrote in > On Fri, Apr 15, 2016 at 11:30 AM, Kyotaro HORIGUCHI < > horiguchi.kyot...@lab.ntt.co.jp> wrote: > > > > At Fri, 15 Apr 2016 08:52:56 +0530, Amit Kapila > wrote : > > > > > > How about if we do all the parsing stuff in temporary context

Re: [HACKERS] Support for N synchronous standby servers - take 2

On Fri, Apr 15, 2016 at 11:30 AM, Kyotaro HORIGUCHI < horiguchi.kyot...@lab.ntt.co.jp> wrote: > > At Fri, 15 Apr 2016 08:52:56 +0530, Amit Kapila wrote : > > > > How about if we do all the parsing stuff in temporary context and then copy > > the results using TopMemoryContext? I don't think it wi

Re: [HACKERS] Support for N synchronous standby servers - take 2

On Fri, Apr 15, 2016 at 3:00 PM, Kyotaro HORIGUCHI wrote: > At Fri, 15 Apr 2016 08:52:56 +0530, Amit Kapila > wrote in >> On Thu, Apr 14, 2016 at 1:10 PM, Masahiko Sawada >> wrote: >> > >> > On Thu, Apr 14, 2016 at 1:11 PM, Kyotaro HORIGUCHI >> > wrote: >> > > At Thu, 14 Apr 2016 12:42:06 +09

Re: [HACKERS] Support for N synchronous standby servers - take 2

At Fri, 15 Apr 2016 08:52:56 +0530, Amit Kapila wrote in > On Thu, Apr 14, 2016 at 1:10 PM, Masahiko Sawada > wrote: > > > > On Thu, Apr 14, 2016 at 1:11 PM, Kyotaro HORIGUCHI > > wrote: > > > At Thu, 14 Apr 2016 12:42:06 +0900, Fujii Masao > wrote in > > > >> > Yes, this is what I was tryin

Re: [HACKERS] Support for N synchronous standby servers - take 2

At Thu, 14 Apr 2016 21:05:40 +0900, Michael Paquier wrote in > > IPC::Run is not installed on Active Perl on my environment and > > Active state seems to be saying that IPC-Run cannot be compiled > > on Windows. ppm doesn't show IPC-Run. Is there any means to do > > TAP test other than this way?

Re: [HACKERS] Support for N synchronous standby servers - take 2

On Thu, Apr 14, 2016 at 1:10 PM, Masahiko Sawada wrote: > > On Thu, Apr 14, 2016 at 1:11 PM, Kyotaro HORIGUCHI > wrote: > > At Thu, 14 Apr 2016 12:42:06 +0900, Fujii Masao wrote in > >> > Yes, this is what I was trying to explain to Fujii-san upthread and I have > >> > also verified that the sa

Re: [HACKERS] Support for N synchronous standby servers - take 2

On Thu, Apr 14, 2016 at 5:48 PM, Kyotaro HORIGUCHI wrote: > At Thu, 14 Apr 2016 17:25:39 +0900 (Tokyo Standard Time), Kyotaro HORIGUCHI > wrote in > <20160414.172539.34325458.horiguchi.kyot...@lab.ntt.co.jp> >> Hello, >> >> At Thu, 14 Apr 2016 13:24:34 +0900, Michael Paquier >> wrote in >>

Re: [HACKERS] Support for N synchronous standby servers - take 2

On Thu, Apr 14, 2016 at 5:25 PM, Kyotaro HORIGUCHI wrote: > diff --git a/src/tools/msvc/vcregress.pl b/src/tools/msvc/vcregress.pl > index 3d14544..08e2acc 100644 > --- a/src/tools/msvc/vcregress.pl > +++ b/src/tools/msvc/vcregress.pl > @@ -548,6 +548,6 @@ sub usage > { > print STDERR >

Re: [HACKERS] Support for N synchronous standby servers - take 2

At Thu, 14 Apr 2016 17:25:39 +0900 (Tokyo Standard Time), Kyotaro HORIGUCHI wrote in <20160414.172539.34325458.horiguchi.kyot...@lab.ntt.co.jp> > Hello, > > At Thu, 14 Apr 2016 13:24:34 +0900, Michael Paquier > wrote in > > > On Thu, Apr 14, 2016 at 11:45 AM, Amit Kapila > > wrote: > > >

Re: [HACKERS] Support for N synchronous standby servers - take 2

Hello, At Thu, 14 Apr 2016 13:24:34 +0900, Michael Paquier wrote in > On Thu, Apr 14, 2016 at 11:45 AM, Amit Kapila wrote: > > Yes, this is what I was trying to explain to Fujii-san upthread and I have > > also verified that the same works on Windows. > > If you could, it would be nice as wel

Re: [HACKERS] Support for N synchronous standby servers - take 2

On Thu, Apr 14, 2016 at 1:11 PM, Kyotaro HORIGUCHI wrote: > At Thu, 14 Apr 2016 12:42:06 +0900, Fujii Masao wrote > in >> > Yes, this is what I was trying to explain to Fujii-san upthread and I have >> > also verified that the same works on Windows. >> >> Oh, okay, understood. Thanks for explai

Re: [HACKERS] Support for N synchronous standby servers - take 2

On Thu, Apr 14, 2016 at 11:45 AM, Amit Kapila wrote: > Yes, this is what I was trying to explain to Fujii-san upthread and I have > also verified that the same works on Windows. If you could, it would be nice as well to check that nothing breaks with VS when using vcregress recoverycheck. -- Mich

Re: [HACKERS] Support for N synchronous standby servers - take 2

At Thu, 14 Apr 2016 12:42:06 +0900, Fujii Masao wrote in > > Yes, this is what I was trying to explain to Fujii-san upthread and I have > > also verified that the same works on Windows. > > Oh, okay, understood. Thanks for explaining that! > > > I think one point which we > > should try to ens

Re: [HACKERS] Support for N synchronous standby servers - take 2

On Thu, Apr 14, 2016 at 11:45 AM, Amit Kapila wrote: > On Wed, Apr 13, 2016 at 1:44 PM, Kyotaro HORIGUCHI > wrote: >> >> At Wed, 13 Apr 2016 04:43:35 +0900, Fujii Masao >> wrote in >> >> > >>> Thank you for reviewing. >> > >>> >> > >>> SyncRepUpdateConfig() seems to be no longer necessary. >> >

Re: [HACKERS] Support for N synchronous standby servers - take 2

On Wed, Apr 13, 2016 at 1:44 PM, Kyotaro HORIGUCHI < horiguchi.kyot...@lab.ntt.co.jp> wrote: > > At Wed, 13 Apr 2016 04:43:35 +0900, Fujii Masao wrote in > > >>> Thank you for reviewing. > > >>> > > >>> SyncRepUpdateConfig() seems to be no longer necessary. > > >> > > >> Really? I was thinking th

Re: [HACKERS] Support for N synchronous standby servers - take 2

At Wed, 13 Apr 2016 04:43:35 +0900, Fujii Masao wrote in > >>> Thank you for reviewing. > >>> > >>> SyncRepUpdateConfig() seems to be no longer necessary. > >> > >> Really? I was thinking that something like that function needs to > >> be called at the beginning of a backend and walsender in > >

Re: [HACKERS] Support for N synchronous standby servers - take 2

On Tue, Apr 12, 2016 at 9:04 AM, Masahiko Sawada wrote: > On Mon, Apr 11, 2016 at 8:47 PM, Fujii Masao wrote: >> On Mon, Apr 11, 2016 at 5:52 PM, Masahiko Sawada >> wrote: >>> On Mon, Apr 11, 2016 at 1:31 PM, Fujii Masao wrote: On Mon, Apr 11, 2016 at 10:58 AM, Masahiko Sawada wrot

Re: [HACKERS] Support for N synchronous standby servers - take 2

On Mon, Apr 11, 2016 at 8:47 PM, Fujii Masao wrote: > On Mon, Apr 11, 2016 at 5:52 PM, Masahiko Sawada > wrote: >> On Mon, Apr 11, 2016 at 1:31 PM, Fujii Masao wrote: >>> On Mon, Apr 11, 2016 at 10:58 AM, Masahiko Sawada >>> wrote: On Sat, Apr 9, 2016 at 12:32 PM, Tom Lane wrote: >

Re: [HACKERS] Support for N synchronous standby servers - take 2

On Mon, Apr 11, 2016 at 5:52 PM, Masahiko Sawada wrote: > On Mon, Apr 11, 2016 at 1:31 PM, Fujii Masao wrote: >> On Mon, Apr 11, 2016 at 10:58 AM, Masahiko Sawada >> wrote: >>> On Sat, Apr 9, 2016 at 12:32 PM, Tom Lane wrote: Jeff Janes writes: > When I compile now without cassert, I

Re: [HACKERS] Support for N synchronous standby servers - take 2

On Mon, Apr 11, 2016 at 1:31 PM, Fujii Masao wrote: > On Mon, Apr 11, 2016 at 10:58 AM, Masahiko Sawada > wrote: >> On Sat, Apr 9, 2016 at 12:32 PM, Tom Lane wrote: >>> Jeff Janes writes: When I compile now without cassert, I get the compiler warning: >>> syncrep.c: In function 'Sync

Re: [HACKERS] Support for N synchronous standby servers - take 2

On Sat, Apr 9, 2016 at 12:32 PM, Tom Lane wrote: > Jeff Janes writes: >> When I compile now without cassert, I get the compiler warning: > >> syncrep.c: In function 'SyncRepUpdateConfig': >> syncrep.c:878:6: warning: variable 'parse_rc' set but not used >> [-Wunused-but-set-variable] Thanks for

Re: [HACKERS] Support for N synchronous standby servers - take 2

On Mon, Apr 11, 2016 at 10:58 AM, Masahiko Sawada wrote: > On Sat, Apr 9, 2016 at 12:32 PM, Tom Lane wrote: >> Jeff Janes writes: >>> When I compile now without cassert, I get the compiler warning: >> >>> syncrep.c: In function 'SyncRepUpdateConfig': >>> syncrep.c:878:6: warning: variable 'parse

Re: [HACKERS] Support for N synchronous standby servers - take 2

On Sat, Apr 9, 2016 at 12:32 PM, Tom Lane wrote: > Jeff Janes writes: >> When I compile now without cassert, I get the compiler warning: > >> syncrep.c: In function 'SyncRepUpdateConfig': >> syncrep.c:878:6: warning: variable 'parse_rc' set but not used >> [-Wunused-but-set-variable] > > If there

Re: [HACKERS] Support for N synchronous standby servers - take 2

Jeff Janes writes: > When I compile now without cassert, I get the compiler warning: > syncrep.c: In function 'SyncRepUpdateConfig': > syncrep.c:878:6: warning: variable 'parse_rc' set but not used > [-Wunused-but-set-variable] If there's a good reason for that to be an Assert, I don't see it. T

Re: [HACKERS] Support for N synchronous standby servers - take 2

On Wed, Apr 6, 2016 at 1:23 AM, Fujii Masao wrote: > Okay, I pushed the patch! > Many thanks to all involved in the development of this feature! Thanks, a nice feature. When I compile now without cassert, I get the compiler warning: syncrep.c: In function 'SyncRepUpdateConfig': syncrep.c:878:6

Re: [HACKERS] Support for N synchronous standby servers - take 2

On Thu, Apr 7, 2016 at 5:49 PM, Fujii Masao wrote: > > On Thu, Apr 7, 2016 at 7:29 PM, Amit Kapila wrote: > > > > So if we go by this each time backend calls pg_stat_get_wal_senders, it > > needs to do parsing to form SyncRepConfig whether it's changed or not from > > previous time. I understand

Re: [HACKERS] Support for N synchronous standby servers - take 2

On Fri, Apr 8, 2016 at 4:50 PM, Fujii Masao wrote: > On Fri, Apr 8, 2016 at 2:26 PM, Michael Paquier > wrote: >> On Thu, Apr 7, 2016 at 11:43 PM, Fujii Masao wrote: >>> On Wed, Apr 6, 2016 at 5:04 PM, Michael Paquier >>> wrote: On Wed, Apr 6, 2016 at 4:08 PM, Michael Paquier wrote: >

Re: [HACKERS] Support for N synchronous standby servers - take 2

On Fri, Apr 8, 2016 at 2:26 PM, Michael Paquier wrote: > On Thu, Apr 7, 2016 at 11:43 PM, Fujii Masao wrote: >> On Wed, Apr 6, 2016 at 5:04 PM, Michael Paquier >> wrote: >>> On Wed, Apr 6, 2016 at 4:08 PM, Michael Paquier >>> wrote: Here are few things I have noticed: + for (i = 0;

Re: [HACKERS] Support for N synchronous standby servers - take 2

On Thu, Apr 7, 2016 at 11:43 PM, Fujii Masao wrote: > On Wed, Apr 6, 2016 at 5:04 PM, Michael Paquier > wrote: >> On Wed, Apr 6, 2016 at 4:08 PM, Michael Paquier >> wrote: >>> Here are few things I have noticed: >>> + for (i = 0; i < max_wal_senders; i++) >>> + { >>> + walsnd = &WalSnd

Re: [HACKERS] Support for N synchronous standby servers - take 2

On Fri, Apr 8, 2016 at 12:55 PM, Thomas Munro wrote: > On Wed, Apr 6, 2016 at 8:23 PM, Fujii Masao wrote: >> >> Okay, I pushed the patch! >> Many thanks to all involved in the development of this feature! > > > Hi, > > I spotted a couple of places in the documentation that still implied there > w

Re: [HACKERS] Support for N synchronous standby servers - take 2

On Wed, Apr 6, 2016 at 8:23 PM, Fujii Masao wrote: > > Okay, I pushed the patch! > Many thanks to all involved in the development of this feature! > Hi, I spotted a couple of places in the documentation that still implied there was only one synchronous standby. Please see suggested fixes attach

Re: [HACKERS] Support for N synchronous standby servers - take 2

On Wed, Apr 6, 2016 at 5:04 PM, Michael Paquier wrote: > On Wed, Apr 6, 2016 at 4:08 PM, Michael Paquier > wrote: >> Here are few things I have noticed: >> + for (i = 0; i < max_wal_senders; i++) >> + { >> + walsnd = &WalSndCtl->walsnds[i]; >> No volatile pointer to prevent code reorder

Re: [HACKERS] Support for N synchronous standby servers - take 2

On Thu, Apr 7, 2016 at 7:29 PM, Amit Kapila wrote: > On Thu, Apr 7, 2016 at 1:30 PM, Amit Langote > wrote: >> >> On 2016/04/07 15:26, Fujii Masao wrote: >> > On Thu, Apr 7, 2016 at 2:48 PM, Amit Kapila >> > wrote: >> >> On Thu, Apr 7, 2016 at 10:02 AM, Fujii Masao >> >> wrote: >> >>> Yes if the

Re: [HACKERS] Support for N synchronous standby servers - take 2

On Thu, Apr 7, 2016 at 1:30 PM, Amit Langote wrote: > > On 2016/04/07 15:26, Fujii Masao wrote: > > On Thu, Apr 7, 2016 at 2:48 PM, Amit Kapila wrote: > >> On Thu, Apr 7, 2016 at 10:02 AM, Fujii Masao wrote: > >>> Yes if the variable that we'd like to pass to a backend is BOOL, INT, > >>> REAL,

Re: [HACKERS] Support for N synchronous standby servers - take 2

On 2016/04/07 15:26, Fujii Masao wrote: > On Thu, Apr 7, 2016 at 2:48 PM, Amit Kapila wrote: >> On Thu, Apr 7, 2016 at 10:02 AM, Fujii Masao wrote: >>> Yes if the variable that we'd like to pass to a backend is BOOL, INT, >>> REAL, STRING or ENUM. But SyncRepConfig variable is a bit more >>> comp

Re: [HACKERS] Support for N synchronous standby servers - take 2

On Thu, Apr 7, 2016 at 11:56 AM, Fujii Masao wrote: > > On Thu, Apr 7, 2016 at 2:48 PM, Amit Kapila wrote: > > On Thu, Apr 7, 2016 at 10:02 AM, Fujii Masao wrote: > >> > >> On Thu, Apr 7, 2016 at 1:22 PM, Amit Kapila > >> wrote: > >> > > >> > But for that, I think we don't need to do anything e

Re: [HACKERS] Support for N synchronous standby servers - take 2

On Thu, Apr 7, 2016 at 2:48 PM, Amit Kapila wrote: > On Thu, Apr 7, 2016 at 10:02 AM, Fujii Masao wrote: >> >> On Thu, Apr 7, 2016 at 1:22 PM, Amit Kapila >> wrote: >> > >> > But for that, I think we don't need to do anything extra. I mean >> > write_nondefault_variables() will automatically wr

Re: [HACKERS] Support for N synchronous standby servers - take 2

On Thu, Apr 7, 2016 at 10:02 AM, Fujii Masao wrote: > > On Thu, Apr 7, 2016 at 1:22 PM, Amit Kapila wrote: > > > > But for that, I think we don't need to do anything extra. I mean > > write_nondefault_variables() will automatically write the non-default value > > of variable and then during back

Re: [HACKERS] Support for N synchronous standby servers - take 2

On Thu, Apr 7, 2016 at 1:22 PM, Amit Kapila wrote: > On Wed, Apr 6, 2016 at 8:11 PM, Fujii Masao wrote: >> >> On Wed, Apr 6, 2016 at 11:14 PM, Amit Kapila >> wrote: >> > On Wed, Apr 6, 2016 at 7:03 PM, Fujii Masao >> > wrote: >> >> >> >> On Wed, Apr 6, 2016 at 8:59 PM, Amit Kapila >> >> wrote:

Re: [HACKERS] Support for N synchronous standby servers - take 2

On Wed, Apr 6, 2016 at 8:11 PM, Fujii Masao wrote: > > On Wed, Apr 6, 2016 at 11:14 PM, Amit Kapila wrote: > > On Wed, Apr 6, 2016 at 7:03 PM, Fujii Masao wrote: > >> > >> On Wed, Apr 6, 2016 at 8:59 PM, Amit Kapila > >> wrote: > >> > > >> >> BTW, we can move SyncRepUpdateConfig() just after Pr

Re: [HACKERS] Support for N synchronous standby servers - take 2

On Wed, Apr 6, 2016 at 11:14 PM, Amit Kapila wrote: > On Wed, Apr 6, 2016 at 7:03 PM, Fujii Masao wrote: >> >> On Wed, Apr 6, 2016 at 8:59 PM, Amit Kapila >> wrote: >> > >> >> BTW, we can move SyncRepUpdateConfig() just after ProcessConfigFile() >> >> from pg_stat_get_wal_senders() and every bac

Re: [HACKERS] Support for N synchronous standby servers - take 2

On Wed, Apr 6, 2016 at 7:03 PM, Fujii Masao wrote: > > On Wed, Apr 6, 2016 at 8:59 PM, Amit Kapila wrote: > > > >> BTW, we can move SyncRepUpdateConfig() just after ProcessConfigFile() > >> from pg_stat_get_wal_senders() and every backends always parse the value > >> of s_s_names when the setting

Re: [HACKERS] Support for N synchronous standby servers - take 2

On Wed, Apr 6, 2016 at 8:59 PM, Amit Kapila wrote: > On Wed, Apr 6, 2016 at 11:17 AM, Fujii Masao wrote: >> >> On Tue, Apr 5, 2016 at 11:40 PM, Amit Kapila >> wrote: >> >> >> >> > 2. >> >> > pg_stat_get_wal_senders() >> >> > { >> >> > .. >> >> > /* >> >> > ! * Allocate and update the config data

Re: [HACKERS] Support for N synchronous standby servers - take 2

On Wed, Apr 6, 2016 at 11:17 AM, Fujii Masao wrote: > > On Tue, Apr 5, 2016 at 11:40 PM, Amit Kapila wrote: > >> > >> > 2. > >> > pg_stat_get_wal_senders() > >> > { > >> > .. > >> > /* > >> > ! * Allocate and update the config data of synchronous replication, > >> > ! * and then get the currently

Re: [HACKERS] Support for N synchronous standby servers - take 2

On 6 April 2016 at 09:23, Fujii Masao wrote: > Okay, I pushed the patch! > Many thanks to all involved in the development of this feature! > Very good. I think the description in the commit message that we don't support "quorum commit" is sufficient to cover my concerns about what others might

Re: [HACKERS] Support for N synchronous standby servers - take 2

On Wed, Apr 6, 2016 at 5:23 PM, Fujii Masao wrote: > Okay, I pushed the patch! > Many thanks to all involved in the development of this feature! I think that I am crying... Really cool to see this milestone accomplished. -- Michael -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgre

Re: [HACKERS] Support for N synchronous standby servers - take 2

On Wed, Apr 6, 2016 at 5:07 PM, Fujii Masao wrote: > On Wed, Apr 6, 2016 at 4:08 PM, Michael Paquier > wrote: >> On Wed, Apr 6, 2016 at 3:29 PM, Fujii Masao wrote: >>> On Wed, Apr 6, 2016 at 2:18 PM, Kyotaro HORIGUCHI >>> wrote: At Tue, 5 Apr 2016 20:17:21 +0900, Fujii Masao wrote i

Re: [HACKERS] Support for N synchronous standby servers - take 2

Sorry, my code was wrong in the case that the total numer of synchronous standby exceeds required number and the wansender is at priority 1. Sorry for the noise. At Wed, 06 Apr 2016 17:01:51 +0900 (Tokyo Standard Time), Kyotaro HORIGUCHI wrote in <20160406.170151.246853881.horiguchi.kyot...@la

Re: [HACKERS] Support for N synchronous standby servers - take 2

On Wed, Apr 6, 2016 at 5:01 PM, Kyotaro HORIGUCHI wrote: > At Wed, 6 Apr 2016 15:29:12 +0900, Fujii Masao wrote > in >> > @@ -640,6 +639,13 @@ SyncRepGetSyncStandbys(bool *am_sync) >> > } >> > >> > /* >> > +* The pending list contains eventually potentially-synchronized

Re: [HACKERS] Support for N synchronous standby servers - take 2

On Wed, Apr 6, 2016 at 4:08 PM, Michael Paquier wrote: > On Wed, Apr 6, 2016 at 3:29 PM, Fujii Masao wrote: >> On Wed, Apr 6, 2016 at 2:18 PM, Kyotaro HORIGUCHI >> wrote: >>> At Tue, 5 Apr 2016 20:17:21 +0900, Fujii Masao >>> wrote in >>> >> list_member_int() performs the loop internall

Re: [HACKERS] Support for N synchronous standby servers - take 2

On Wed, Apr 6, 2016 at 4:08 PM, Michael Paquier wrote: > Here are few things I have noticed: > + for (i = 0; i < max_wal_senders; i++) > + { > + walsnd = &WalSndCtl->walsnds[i]; > No volatile pointer to prevent code reordering? > > */ > typedef struct WalSnd > { > + int slotno;

Re: [HACKERS] Support for N synchronous standby servers - take 2

At Wed, 6 Apr 2016 15:29:12 +0900, Fujii Masao wrote in > > @@ -640,6 +639,13 @@ SyncRepGetSyncStandbys(bool *am_sync) > > } > > > > /* > > +* The pending list contains eventually potentially-synchronized > > standbys > > +* and this walsender may be one of them.

Re: [HACKERS] Support for N synchronous standby servers - take 2

On Wed, Apr 6, 2016 at 3:29 PM, Fujii Masao wrote: > On Wed, Apr 6, 2016 at 2:18 PM, Kyotaro HORIGUCHI > wrote: >> At Tue, 5 Apr 2016 20:17:21 +0900, Fujii Masao wrote >> in >>> >> list_member_int() performs the loop internally. So I'm not sure how much >>> >> adding extra list_member_int() he

Re: [HACKERS] Support for N synchronous standby servers - take 2

On Wed, Apr 6, 2016 at 2:51 PM, Masahiko Sawada wrote: > On Wed, Apr 6, 2016 at 2:21 PM, Fujii Masao wrote: >> On Tue, Apr 5, 2016 at 8:51 PM, Simon Riggs wrote: >>> On 5 April 2016 at 12:26, Fujii Masao wrote: >>> Multiple standbys with the same name may connect to the master. I

Re: [HACKERS] Support for N synchronous standby servers - take 2

On Wed, Apr 6, 2016 at 2:18 PM, Kyotaro HORIGUCHI wrote: > At Tue, 5 Apr 2016 20:17:21 +0900, Fujii Masao wrote > in >> >> list_member_int() performs the loop internally. So I'm not sure how much >> >> adding extra list_member_int() here can optimize this processing. >> >> Another idea is to ma

Re: [HACKERS] Support for N synchronous standby servers - take 2

On Wed, Apr 6, 2016 at 2:51 PM, Masahiko Sawada wrote: > On Wed, Apr 6, 2016 at 2:21 PM, Fujii Masao wrote: >> On Tue, Apr 5, 2016 at 8:51 PM, Simon Riggs wrote: >>> On 5 April 2016 at 12:26, Fujii Masao wrote: >>> Multiple standbys with the same name may connect to the master. I

Re: [HACKERS] Support for N synchronous standby servers - take 2

On Wed, Apr 6, 2016 at 2:21 PM, Fujii Masao wrote: > On Tue, Apr 5, 2016 at 8:51 PM, Simon Riggs wrote: >> On 5 April 2016 at 12:26, Fujii Masao wrote: >> >>> >>> Multiple standbys with the same name may connect to the master. >>> In this case, users might want to specifiy k<=N. So k<=N seems no

Re: [HACKERS] Support for N synchronous standby servers - take 2

On Tue, Apr 5, 2016 at 11:47 PM, Robert Haas wrote: > On Mon, Apr 4, 2016 at 4:28 AM, Fujii Masao wrote: + ereport(LOG, + (errmsg("standby \"%s\" is now the synchronous standby with priority %u", + application_name, MyWalSnd->sync_standby_priority))); s/ the / a / >> >> I

Re: [HACKERS] Support for N synchronous standby servers - take 2

On Tue, Apr 5, 2016 at 11:40 PM, Amit Kapila wrote: > On Tue, Apr 5, 2016 at 3:15 PM, Fujii Masao wrote: >> >> On Tue, Apr 5, 2016 at 4:31 PM, Amit Kapila >> wrote: >> > On Mon, Apr 4, 2016 at 1:58 PM, Fujii Masao >> > wrote: >> >> >> >> >> >> Thanks for updating the patch! >> >> >> >> I applie

Re: [HACKERS] Support for N synchronous standby servers - take 2

On Tue, Apr 5, 2016 at 8:51 PM, Simon Riggs wrote: > On 5 April 2016 at 12:26, Fujii Masao wrote: > >> >> Multiple standbys with the same name may connect to the master. >> In this case, users might want to specifiy k<=N. So k<=N seems not invalid >> setting. > > > Confusing as that is, it is alr

Re: [HACKERS] Support for N synchronous standby servers - take 2

At Tue, 5 Apr 2016 20:17:21 +0900, Fujii Masao wrote in > >> list_member_int() performs the loop internally. So I'm not sure how much > >> adding extra list_member_int() here can optimize this processing. > >> Another idea is to make SyncRepGetSyncStandby() check whether I'm sync > >> standby or

Re: [HACKERS] Support for N synchronous standby servers - take 2

On Tue, Apr 5, 2016 at 7:23 PM, Kyotaro HORIGUCHI wrote: > At Mon, 4 Apr 2016 22:00:24 +0900, Masahiko Sawada > wrote in >> > For this case, the tree members of SyncRepConfig are '2[Sby1,', >> > 'Sby2', "Sby3]'. This syntax is valid for the current >> > specification but will surely get differe

Re: [HACKERS] Support for N synchronous standby servers - take 2

On Mon, Apr 4, 2016 at 4:28 AM, Fujii Masao wrote: >>> + ereport(LOG, >>> + (errmsg("standby \"%s\" is now the synchronous standby with priority %u", >>> + application_name, MyWalSnd->sync_standby_priority))); >>> >>> s/ the / a / > > I have no objection to this change itself. But we have used thi

Re: [HACKERS] Support for N synchronous standby servers - take 2

On Tue, Apr 5, 2016 at 3:15 PM, Fujii Masao wrote: > > On Tue, Apr 5, 2016 at 4:31 PM, Amit Kapila wrote: > > On Mon, Apr 4, 2016 at 1:58 PM, Fujii Masao wrote: > >> > >> > >> Thanks for updating the patch! > >> > >> I applied the following changes to the patch. > >> Attached is the revised vers

Re: [HACKERS] Support for N synchronous standby servers - take 2

On 5 April 2016 at 12:26, Fujii Masao wrote: > Multiple standbys with the same name may connect to the master. > In this case, users might want to specifiy k<=N. So k<=N seems not invalid > setting. Confusing as that is, it is already the case; k > N could make sense. ;-( However, in most cas

Re: [HACKERS] Support for N synchronous standby servers - take 2

On Tue, Apr 5, 2016 at 8:08 PM, Simon Riggs wrote: > On 5 April 2016 at 11:18, Fujii Masao wrote: > >> >> > 1. Header comments in syncrep.c need changes, not just additions. >> >> Okay, will consider this later. And I'd appreciate if you elaborate what >> changes are necessary specifically. > > >

Re: [HACKERS] Support for N synchronous standby servers - take 2

On 5 April 2016 at 11:23, Fujii Masao wrote: > On Tue, Apr 5, 2016 at 6:09 PM, Simon Riggs wrote: > > On 5 April 2016 at 08:58, Amit Langote > > wrote: > > > >> > >> So I am suggesting we put an extra keyword in front of the “k”, to > >> > explain how the k responses should be gathered as

Re: [HACKERS] Support for N synchronous standby servers - take 2

On Tue, Apr 5, 2016 at 7:17 PM, Kyotaro HORIGUCHI wrote: > At Tue, 5 Apr 2016 18:08:20 +0900, Fujii Masao wrote > in >> On Mon, Apr 4, 2016 at 10:00 PM, Masahiko Sawada >> wrote: >> > On Mon, Apr 4, 2016 at 6:03 PM, Kyotaro HORIGUCHI >> > wrote: >> >> Hello, thank you for testing. >> >> >> >

Re: [HACKERS] Support for N synchronous standby servers - take 2

On 5 April 2016 at 11:18, Fujii Masao wrote: > > 1. Header comments in syncrep.c need changes, not just additions. > > Okay, will consider this later. And I'd appreciate if you elaborate what > changes are necessary specifically. Some of the old header comments are now wrong. > > 2. We need

Re: [HACKERS] Support for N synchronous standby servers - take 2

On Tue, Apr 5, 2016 at 6:09 PM, Simon Riggs wrote: > On 5 April 2016 at 08:58, Amit Langote > wrote: > >> >> So I am suggesting we put an extra keyword in front of the “k”, to >> > explain how the k responses should be gathered as an extension to the >> > the >> > syntax. I also think implem

Re: [HACKERS] Support for N synchronous standby servers - take 2

At Mon, 4 Apr 2016 22:00:24 +0900, Masahiko Sawada wrote in > > For this case, the tree members of SyncRepConfig are '2[Sby1,', > > 'Sby2', "Sby3]'. This syntax is valid for the current > > specification but will surely get different meaning by the future > > changes. We should refuse this known

Re: [HACKERS] Support for N synchronous standby servers - take 2

On Tue, Apr 5, 2016 at 4:35 PM, Simon Riggs wrote: > On 4 April 2016 at 10:35, Simon Riggs wrote: >> >> On 4 April 2016 at 09:28, Fujii Masao wrote: >> >>> >>> Barring any objections, I'll commit this patch. >> >> >> That sounds good. >> >> May I have one more day to review this? Actually more l

Re: [HACKERS] Support for N synchronous standby servers - take 2

At Tue, 5 Apr 2016 18:08:20 +0900, Fujii Masao wrote in > On Mon, Apr 4, 2016 at 10:00 PM, Masahiko Sawada > wrote: > > On Mon, Apr 4, 2016 at 6:03 PM, Kyotaro HORIGUCHI > > wrote: > >> Hello, thank you for testing. > >> > >> At Sat, 2 Apr 2016 14:20:55 +1300, Thomas Munro > >> wrote in >

Re: [HACKERS] Support for N synchronous standby servers - take 2

On Tue, Apr 5, 2016 at 4:31 PM, Amit Kapila wrote: > On Mon, Apr 4, 2016 at 1:58 PM, Fujii Masao wrote: >> >> >> Thanks for updating the patch! >> >> I applied the following changes to the patch. >> Attached is the revised version of the patch. >> > > 1. >{ > {"synchronous_standby_names",

Re: [HACKERS] Support for N synchronous standby servers - take 2

On 2016-04-05 10:13:50 +0100, Simon Riggs wrote: > The lack of per-database settings is not a blocker for me. Just to clarify: Neither is it for me. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgs

Re: [HACKERS] Support for N synchronous standby servers - take 2

On 5 April 2016 at 10:10, Fujii Masao wrote: > On Mon, Apr 4, 2016 at 6:45 PM, Andres Freund wrote: > > On 2016-04-04 10:35:34 +0100, Simon Riggs wrote: > >> On 4 April 2016 at 09:28, Fujii Masao wrote: > >> > Barring any objections, I'll commit this patch. > > > > No objection here either, jus

Re: [HACKERS] Support for N synchronous standby servers - take 2

On Mon, Apr 4, 2016 at 6:45 PM, Andres Freund wrote: > On 2016-04-04 10:35:34 +0100, Simon Riggs wrote: >> On 4 April 2016 at 09:28, Fujii Masao wrote: >> > Barring any objections, I'll commit this patch. > > No objection here either, just one question: Has anybody thought about > the ability to

Re: [HACKERS] Support for N synchronous standby servers - take 2

On 5 April 2016 at 08:58, Amit Langote wrote: > So I am suggesting we put an extra keyword in front of the “k”, to > > explain how the k responses should be gathered as an extension to the the > > syntax. I also think implementing “any k” is actually fairly trivial and > > could be done for

Re: [HACKERS] Support for N synchronous standby servers - take 2

On Mon, Apr 4, 2016 at 10:00 PM, Masahiko Sawada wrote: > On Mon, Apr 4, 2016 at 6:03 PM, Kyotaro HORIGUCHI > wrote: >> Hello, thank you for testing. >> >> At Sat, 2 Apr 2016 14:20:55 +1300, Thomas Munro >> wrote in >> >>> >>> Attached latest patch incorporate some review comments so far, and

Re: [HACKERS] Support for N synchronous standby servers - take 2

On Mon, Apr 4, 2016 at 5:59 PM, Abhijit Menon-Sen wrote: > At 2016-04-04 17:28:07 +0900, masao.fu...@gmail.com wrote: >> >> Barring any objections, I'll commit this patch. > > No objections, just a minor wording tweak: > > doc/src/sgml/config.sgml: > > "The synchronous standbys will be the standby

Re: [HACKERS] Support for N synchronous standby servers - take 2

On 2016/04/05 16:35, Simon Riggs wrote: > 6. Meaning of k (n1, n2, n3) with N servers > > It's clearly documented that this means k replies IN SEQUENCE. I believe > the typical meaning of would be “any k out of N”, which would be faster > than what we have, e.g. >3 (n1, n2, n3) would release a

Re: [HACKERS] Support for N synchronous standby servers - take 2

On 4 April 2016 at 10:35, Simon Riggs wrote: > On 4 April 2016 at 09:28, Fujii Masao wrote: > > >> Barring any objections, I'll commit this patch. >> > > That sounds good. > > May I have one more day to review this? Actually more like 3-4 hours. > What we have here is useful and elegant. I love

Re: [HACKERS] Support for N synchronous standby servers - take 2

On Mon, Apr 4, 2016 at 1:58 PM, Fujii Masao wrote: > > > Thanks for updating the patch! > > I applied the following changes to the patch. > Attached is the revised version of the patch. > 1. { {"synchronous_standby_names", PGC_SIGHUP, REPLICATION_MASTER, gettext_noop("List of names of pote

Re: [HACKERS] Support for N synchronous standby servers - take 2

On 4 April 2016 at 10:45, Andres Freund wrote: > > Simon, perhaps you could hold the above question in your mind while > looking through this? > Sure, np. -- Simon Riggshttp://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, T

  1   2   3   4   >