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

Re: disposition of remaining patches

From: Daniel Farina <daniel(at)heroku(dot)com>
To: Greg Smith <greg(at)2ndquadrant(dot)com>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: disposition of remaining patches
Date: 2011-02-25 08:14:18
Message-ID: AANLkTiny3piBqS_FAf9gN-Ws5Ok06Y7xwoMD4iRQqL=_@mail.gmail.com (view raw or flat)
Thread:
Lists: pgsql-hackers
On Wed, Feb 23, 2011 at 11:49 AM, Greg Smith <greg(at)2ndquadrant(dot)com> wrote:
> Robert Haas wrote:
>>>
>>> 2. Synchronous replication.  Splitting up this patch has allowed some
> On top of 4 listed reviewers I know Dan Farina is poking at the last update,
> so we may see one more larger report on top of what's already shown up.  And
> Jaime keeps kicking the tires too.  What Simon was hoping is that a week of
> others looking at this would produce enough feedback that it might be
> possible to sweep the remaining issues up soon after he's back.  It looks to
> me like that's about when everything else that's still open will probably
> settle too.

Besides some of the fixable issues, I am going to have to echo
Robert's sentiments about a few kinks that go beyond mechanism in the
syncrep patch: in particular, it will *almost* solve the use case I
was hoping to solve: a way to cleanly perform planned switchovers
between machines with minimal downtime and no lost data. But there are
a couple of holes I have thought of so far:

1. The 2-safe methodology supported is not really compatible with
performing planned-HA-switchover of a cluster with its own syncrep
guarantees on top of that. For example:

Server A syncreps to Server B

Now I want to provision server A-prime, which will eventually take the
place of A.

Server A syncreps to Server B
Server A syncreps to Server A-prime

Right now, as it stands, the syncrep patch will be happy as soon as
the data has been fsynced to either B or A-prime; I don't think we can
guarantee at any point that A-prime can become the leader, and feed B.

2. The unprivileged user can disable syncrep, in any situation. This
flexibility is *great*, but you don't really want people to do it when
one is performing the switchover. Rather, in a magical world we'd hope
that disabling syncrep would just result in not having to
synchronously commit to B (but, in this case, still synchronously
commit to A-prime)

In other words, to my mind, you can use syncrep as-is to provide
2-safe durability xor a scheduled switchover: as soon as someone wants
both, I think they'll have some trouble. I do want both, though.

-- 
fdr

In response to

Responses

pgsql-hackers by date

Next:From: Robert HaasDate: 2011-02-25 12:43:06
Subject: Re: disposition of remaining patches
Previous:From: Bruce MomjianDate: 2011-02-25 06:33:59
Subject: Re: WIP: cross column correlation ...

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