Re: Core team statement on replication in PostgreSQL - Mailing list pgsql-hackers

From Bruce Momjian
Subject Re: Core team statement on replication in PostgreSQL
Date
Msg-id 200806100125.m5A1PHP08818@momjian.us
Whole thread Raw
In response to Re: Core team statement on replication in PostgreSQL  ("Gurjeet Singh" <singh.gurjeet@gmail.com>)
Responses Re: Core team statement on replication in PostgreSQL  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
Gurjeet Singh wrote:
> On Fri, May 30, 2008 at 10:40 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> 
> > But since you mention it: one of the plausible answers for fixing the
> > vacuum problem for read-only slaves is to have the slaves push an xmin
> > back upstream to the master to prevent premature vacuuming.  The current
> > design of pg_standby is utterly incapable of handling that requirement.
> > So there might be an implementation dependency there, depending on how
> > we want to solve that problem.
> >
> 
> I think it would be best to not make the slave interfere with the master's
> operations; that's only going to increase the operational complexity of such
> a solution.
> 
> There could be multiple slaves following a master, some serving

For the slave to not interfere with the master at all, we would need to
delay application of WAL files on each slave until visibility on that
slave allows the WAL to be applied, but in that case we would have
long-running transactions delay data visibility of all slave sessions.

--  Bruce Momjian  <bruce@momjian.us>        http://momjian.us EnterpriseDB
http://enterprisedb.com
 + If your life is a hard drive, Christ can be your backup. +


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Proposal: GiST constraints
Next
From: Bruce Momjian
Date:
Subject: Re: Core team statement on replication in PostgreSQL