On Sat, Sep 13, 2014 at 3:56 AM, Robert Haas <robertmhaas@gmail.com> wrote:
> 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.
Reading both your answers, I'd tend to think that having a set of
hooks to satisfy all the potential user requests would be enough. We
could let the server code decide what is the priority of the standbys
using the information in synchronous_standby_names, then have the
hooks interact with SyncRepReleaseWaiters and pg_stat_get_wal_senders.
We would need two hooks:
- one able to get an array of WAL sender position defining all the
nodes considered as sync nodes. This is enough for
pg_stat_get_wal_senders. SyncRepReleaseWaiters would need it as
well...
- a second able to define the update policy of the write and flush
positions in walsndctl (SYNC_REP_WAIT_FLUSH and SYNC_REP_WAIT_WRITE),
as well as the next failover policy. This would be needed for
SyncRepReleaseWaiters when a WAL sender calls SyncRepReleaseWaiters.
Perhaps that's overthinking, but I am getting the impression that
whatever the decision taken, it would involve modifications of the
sync-standby parametrization at GUC level, and whatever the path
chosen (dedicated language, set of integer params), there will be
complains about what things can or cannot be done.
At least a set of hooks has the merit to say: do what you like with
your synchronous node policy.
--
Michael