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

Re: Synchronous replication, network protocol

From: Simon Riggs <simon(at)2ndQuadrant(dot)com>
To: Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>
Cc: Fujii Masao <masao(dot)fujii(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, Pavan Deolasee <pavan(dot)deolasee(at)enterprisedb(dot)com>
Subject: Re: Synchronous replication, network protocol
Date: 2008-12-23 17:15:08
Message-ID: 1230052508.4793.913.camel@ebony.2ndQuadrant (view raw or flat)
Thread:
Lists: pgsql-hackers
On Tue, 2008-12-23 at 18:23 +0200, Heikki Linnakangas wrote:
> (later) OldestXmin <xid>
>         When a hot standby server is running read-only queries,
> indicates the 
> current OldestXmin on the standby. The primary can refrain from 
> vacuuming tuples still required by the slave using this value, if so 
> configured. 

This is all reading like you are relaying someone else's thoughts, or
that of a committee. 

The above is the exact opposite of your position on 11 Sep, where you
said having a matching xmin between primary and standby "makes an awful
solution for high availability" which Richard, Greg, Robert at least
agreed explicitly with. 

I *am* happy to rediscuss this aspect, because I think you may now see
the problems with what people had earlier ruled out. But it would be
good to understand why the 180 degree manoeuvre before we start coding
up protocol changes.

> That will ensure that the standby doesn't need to stall WAL 
> application because of read-only queries.

It doesn't need to. That is already optional.

-- 
 Simon Riggs           www.2ndQuadrant.com
 PostgreSQL Training, Services and Support


In response to

Responses

pgsql-hackers by date

Next:From: Stephan SzaboDate: 2008-12-23 17:15:38
Subject: Re: incoherent view of serializable transactions
Previous:From: Gregory StarkDate: 2008-12-23 17:04:11
Subject: Re: incoherent view of serializable transactions

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