Horton

Re: Configuring synchronous replication

Robert Haas <robertmhaas@gmail.com>

View thread
From: Robert Haas <robertmhaas@gmail.com>
To: Simon Riggs <simon@2ndquadrant.com>
Cc: Aidan Van Dyk <aidan@highrise.ca>, Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>, Fujii Masao <masao.fujii@gmail.com>, David Fetter <david@fetter.org>, Heikki Linnakangas <heikki@postgresql.org>, pgsql-hackers@postgresql.org
Date: 2010-09-17T15:23:53Z
Lists: pgsql-hackers 
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...

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise Postgres Company