Skip site navigation (1) Skip section navigation (2)

Re: Sync Rep Design

From: Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>
To: Hannu Krosing <hannu(at)2ndquadrant(dot)com>
Cc: Simon Riggs <simon(at)2ndQuadrant(dot)com>, greg(at)2ndQuadrant(dot)com, Josh Berkus <josh(at)postgresql(dot)org>, Robert Haas <robertmhaas(at)gmail(dot)com>, Stefan Kaltenbrunner <stefan(at)kaltenbrunner(dot)cc>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Sync Rep Design
Date: 2011-01-01 19:41:55
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
On 31.12.2010 23:18, Hannu Krosing wrote:
> On 31.12.2010 13:40, Heikki Linnakangas wrote:
>> That thread makes no mention of how to specify which standbys are
>> synchronous and which are not.
> The simplest way would be to have separate database users for sync and
> async standbys ?
> That would allow any standby with right credentials act as a sync user,
> and those who are not eligible are not accepted even if they try to act
> as "a synchronity (?) provider".

Hmm, access control... We haven't yet discussed what privileges a 
standby needs to become synchronous. Perhaps it needs to be a separate 
privilege that can be granted, in addition to the replication privilege?

Robert's suggestion of using the roles instead of server names would 
also solve that. With that you would list the roles in 
synchronous_standbys, and no-one else could become a synchronous 
standby. The downside is that if you want to have two standbys in the 
mode that it's enough that either one acknowledges a commit, they would 
have to use the same user account.

If we don't adopt Robert's suggestion, do we want to restrict what 
standby name a user can claim, to stop one standby from spoofing another?

   Heikki Linnakangas

In response to


pgsql-hackers by date

Next:From: Peter EisentrautDate: 2011-01-01 20:24:01
Subject: Re: TODO item for pg_ctl and server detection
Previous:From: Heikki LinnakangasDate: 2011-01-01 19:29:45
Subject: Re: Sync Rep Design

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group