From: Josh Berkus <josh@postgresql.org>
To: Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>
Cc: Stefan Kaltenbrunner <stefan@kaltenbrunner.cc>
Cc: Simon Riggs <simon@2ndQuadrant.com>
Cc: greg@2ndQuadrant.com, Hannu Krosing <hannu@2ndquadrant.com>
Cc: Robert Haas <robertmhaas@gmail.com>
Cc: pgsql-hackers@postgresql.org
Subject: Re: Sync Rep Design
Date: Tue, 04 Jan 2011 10:40:25 -0800
Message-ID: <4D236999.4050905@postgresql.org> (raw)
In-Reply-To: <4D2038BB.7000504@enterprisedb.com>
References: <1293729972.1892.23804.camel@ebony>
<4D1CC47E.7050207@kaltenbrunner.cc>
<1293735853.1892.24886.camel@ebony>
<AANLkTi=SvN2KQ1Tzh-tRKcXD0i2FyWFBbbR=kXXdepqN@mail.gmail.com>
<4D1D8B2F.5070001@2ndquadrant.com>
<4D1DAB14.5000800@enterprisedb.com>
<1293796137.1892.37313.camel@ebony>
<4D1DCF5A.7070808@enterprisedb.com>
<1293822959.1892.43164.camel@ebony>
<4D1F332A.90306@kaltenbrunner.cc>
<4D1FAD55.1090304@postgresql.org>
<4D2038BB.7000504@enterprisedb.com>
On 1/2/11 12:35 AM, Heikki Linnakangas wrote:
> Very likely. A synchronous standby can bring the master to a halt, while
> an asynchronous one is rather harmless. If I were a DBA, and the data
> wasn't very sensitive, I would liberally hand out async privileges to my
> colleagues to set up reporting standbys, test servers etc. But I would
> *not* give them synchronous privileges, because sooner or later one
> would go "hmm, I wonder what happens if I make this synchronous", or
> haphazardly copy the config file from a synchronous standby. That would
> either bring down the master, or act as a "fake" standby, acknowledging
> commits before they're flushed to the real synchronous standby. Either
> one would be bad.
That's not "very likely". Shops with enough DBAs to actually have a
heirarchy of database access are rare indeed; the average business has
trouble employing *one* fulltime DBA. Also, you're mistaken if you
think that DBA's wouldn't restrict the ability of development users to
set up asynch connections; those have a significant impact on the
production server as well.
However, the possibility of *accidental* DOS is a bit more likely, per
accidentally using the wrong config file. I don't think you can guard
against that with permissions, though; if a DBA is copying the config
file from a synchronous server accidentally, presumably he's copying the
.pgpass file as well, and then the new server is identical to the legit
synch rep servers as far as the master is concerned.
So, again, I don't agree that a separate synchrep permission is useful,
or warranted.
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.
--Josh Berkus
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-hackers@postgresql.org
Cc: josh@postgresql.org, heikki.linnakangas@enterprisedb.com, stefan@kaltenbrunner.cc, simon@2ndQuadrant.com, hannu@2ndquadrant.com, robertmhaas@gmail.com
Subject: Re: Sync Rep Design
In-Reply-To: <4D236999.4050905@postgresql.org>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox