Re: Standby registration - Mailing list pgsql-hackers

From Dimitri Fontaine
Subject Re: Standby registration
Date
Msg-id 87k4mclrhm.fsf@hi-media-techno.com
Whole thread Raw
In response to Standby registration  (Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>)
Responses Re: Standby registration  (Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>)
Re: Standby registration  (Fujii Masao <masao.fujii@gmail.com>)
List pgsql-hackers
Heikki Linnakangas <heikki.linnakangas@enterprisedb.com> writes:
> Having mulled through all the recent discussions on synchronous replication,
> ISTM there is pretty wide consensus that having a registry of all standbys
> in the master is a good idea. Even those who don't think it's *necessary*
> for synchronous replication seem to agree that it's nevertheless a pretty
> intuitive way to configure it. And it has some benefits even if we never get
> synchronous replication.

Yeah it's nice to have, but I disagree with it being a nice way to
configure it. I still think that in the long run it's more hassle than a
distributed setup to maintain.

> The consensus seems to be use a configuration file called
> standby.conf. Let's use the "ini file format" for now [1].

What about automatic registration of standbys? That's not going to fly
with the unique global configuration file idea, but that's good news.

Automatic registration is a good answer to both your points A)
monitoring and C) wal_keep_segments, but needs some more thinking wrt
security and authentication.

What about having a new GRANT privilege for replication, so that any
standby can connect with a non-superuser role as soon as the master's
setup GRANTS replication to the role? You still need HBA setup to be
accepting the slave, too, of course.

Regards,
-- 
dim


pgsql-hackers by date:

Previous
From: Pavel Stehule
Date:
Subject: Re: wip: functions median and percentile
Next
From: Magnus Hagander
Date:
Subject: Re: Git cvsserver serious issue