Re: Support for N synchronous standby servers

On Fri, Sep 12, 2014 at 2:44 PM, Gregory Smith <gregsmithpgsql(at)gmail(dot)com> wrote:
> On 9/12/14, 2:28 PM, Robert Haas wrote:
>> I hate to be the guy always suggesting a mini-language (cf. recent
>> discussion of an expression syntax for pgbench), but we could do much more
>> powerful and flexible things here if we had one. For example, suppose we let
>> each element of synchronous_standby_names use the constructs (X,Y,Z,...)
>
> While I have my old list history hat on this afternoon, when the 9.1
> deadline was approaching I said that some people were not going to be happy
> until "is it safe to commit?" calls an arbitrary function that is passed the
> names of all the active servers, and then they could plug whatever consensus
> rule they wanted into there. And then I said that if we actually wanted to
> ship something, it should be some stupid simple thing like just putting a
> list of servers in synchronous_standby_names and proceeding if one is
> active. One of those two ideas worked out...
>
> Can you make a case for why it needs to be a mini-language instead of a
> function?

I think so. If we make it a function, then it's either the kind of
function that you access via pg_proc, or it's the kind that's written
in C and installed by storing a function pointer in a hook variable
from _PG_init(). The first approach is a non-starter because it would
require walsender to be connected to the database where that function
lives, which is a non-starter at least for logical replication where
we need walsender to be connected to the database being replicated.
Even if we found some way around that problem, and I'm not sure there
is one, I suspect the overhead would be pretty high. The second
approach - a hook that can be accessed directly by loadable modules -
seems like it would work fine; the only problem that is that you've
got to write your policy function in C. But I have no issue with
exposing it that way if someone wants to write a patch. There is no
joy in getting between the advanced user and his nutty-complicated
sync rep configuration. However, I suspect that most users will
prefer a more user-friendly interface.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company