Re: Support for N synchronous standby servers - take 2 - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Support for N synchronous standby servers - take 2
Date
Msg-id 476.1461420723@sss.pgh.pa.us
Whole thread Raw
In response to Re: Support for N synchronous standby servers - take 2  (Amit Kapila <amit.kapila16@gmail.com>)
Responses Re: Support for N synchronous standby servers - take 2
List pgsql-hackers
Amit Kapila <amit.kapila16@gmail.com> 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 proposed
v7 patch is flat out not acceptable, not now and not for 9.7 either,
because it introduces a GUC assign hook that can easily fail (eg, through
out-of-memory for the copy step).  Assign hook functions need to be
incapable of failure.  I do not see any good reason why this one cannot
satisfy that requirement, either.  It just needs to make use of the
"extra" mechanism to pass back an already-suitably-long-lived result from
check_synchronous_standby_names.  See check_timezone_abbreviations/
assign_timezone_abbreviations for a model to follow.  You are going to
need to find a way to package the parse result into a single malloc'd
blob, though, because that's as much as guc.c can keep track of for an
"extra" value.
        regards, tom lane



pgsql-hackers by date:

Previous
From: Amit Kapila
Date:
Subject: Re: Support for N synchronous standby servers - take 2
Next
From: Bruce Momjian
Date:
Subject: Re: snapshot too old, configured by time