Re: Configuring synchronous replication - Mailing list pgsql-hackers

From Simon Riggs
Subject Re: Configuring synchronous replication
Date
Msg-id 1284738584.1733.5081.camel@ebony
Whole thread Raw
In response to Re: Configuring synchronous replication  (Aidan Van Dyk <aidan@highrise.ca>)
List pgsql-hackers
On Fri, 2010-09-17 at 11:30 -0400, Aidan Van Dyk wrote:
> * Robert Haas <robertmhaas@gmail.com> [100917 11:24]:
> > On Fri, Sep 17, 2010 at 11:22 AM, Simon Riggs <simon@2ndquadrant.com> wrote:
> > > On Fri, 2010-09-17 at 09:36 -0400, Aidan Van Dyk wrote:
> > >
> > >> I want to have them configured in a fsync WAL/style sync rep, I want to
> > >> make sure that if the master comes up first after I get power back, it's
> > >> not going to be claiming transactions are committed while the slave
> > >> (which happens to have 4x the disks because it keeps PITR backups for a
> > >> period too) it still chugging away on SCSI probes yet, not gotten to
> > >> having PostgreSQL up yet...
> > >
> > > Nobody has mentioned the ability to persist the not-committed state
> > > across a crash before, and I think it's an important discussion point.
> > 
> > Eh?  I think all Aidan is asking for is the ability to have a mode
> > where sync rep is really always sync, or nothing commits.  Rather than
> > timing out and continuing merrily on its way...
> 
> Right, I'm not asking for a "new" mode.  I'm just hope that there will
> be a way to guarantee my "sync rep" is actually replicating.  Having it
> "not replicate" simply because no slave has (yet) connected means I have
> to dance jigs around pg_hba.conf so that it won't allow non-replication
> connections until I've manual verified that the replication slave
> is connected...

I agree that aspect is a problem.

One solution, to me, would be to have a directive included in the
pg_hba.conf that says entries below it are only allowed if it passes the
test. So your hba file looks like this

local    postgres    postgres
host    replication    ...
need    replication 
host    any        any    

So the "need" test is an extra option in the first column. We might want
additional "need" tests before we allow other rules also. Text following
the "need" verb will be additional info for that test, sufficient to
allow some kind of execution on the backend.

I definitely don't like the idea that anyone that commits will just sit
there waiting until the standby comes up. That just sounds an insane way
of doing it.

-- Simon Riggs           www.2ndQuadrant.comPostgreSQL Development, 24x7 Support, Training and Services



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Report: removing the inconsistencies in our CVS->git conversion
Next
From: Robert Haas
Date:
Subject: Re: bg worker: general purpose requirements