| From: | Dimitri Fontaine <dimitri(at)2ndQuadrant(dot)fr> |
|---|---|
| To: | Josh Berkus <josh(at)postgresql(dot)org> |
| Cc: | Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>, Stefan Kaltenbrunner <stefan(at)kaltenbrunner(dot)cc>, Simon Riggs <simon(at)2ndQuadrant(dot)com>, greg(at)2ndQuadrant(dot)com, Hannu Krosing <hannu(at)2ndquadrant(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, pgsql-hackers(at)postgresql(dot)org |
| Subject: | Re: Sync Rep Design |
| Date: | 2011-01-04 22:00:53 |
| Message-ID: | m2sjx8l46i.fsf@2ndQuadrant.fr |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Josh Berkus <josh(at)postgresql(dot)org> writes:
> So, again, I don't agree that a separate synchrep permission is useful,
> or warranted.
+1
> However, your arguments *do* make me backpedal on the issue of having a
> list of synch rep roles on the master. I can easily imagine a DBA
> needing to rapidly disable synch rep if replication is failing, without
> taking the time to log in to several separate standbys, one or more of
> which might be improperly configured and inaccessible. I can't think of
> a simpler way to do that than having a synch_rep_roles configuration on
> the master. That would also handle control issues for the senior DBA,
> since you'd need superuser access to the master to modify it.
What about the HBA here?
Regards,
--
Dimitri Fontaine
http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Josh Berkus | 2011-01-04 22:18:13 | Re: Sync Rep Design |
| Previous Message | Mark Kirkwood | 2011-01-04 21:49:43 | Re: Re: Vacuum of newly activated 8.3.12 standby receives warnings page xxx is uninitialized --- fixing |