Re: Core team statement on replication in PostgreSQL

On Fri, 2008-05-30 at 15:16 -0400, Robert Treat wrote:
> On Friday 30 May 2008 01:10:20 Tom Lane wrote:
> > Greg Smith <gsmith(at)gregsmith(dot)com> writes:
> > > I fully accept that it may be the case that it doesn't make technical
> > > sense to tackle them in any order besides sync->read-only slaves because
> > > of dependencies in the implementation between the two.
> >
> > Well, it's certainly not been my intention to suggest that no one should
> > start work on read-only-slaves before we finish the other part. The
> > point is that I expect the log shipping issues will be done first
> > because they're easier, and it would be pointless to not release that
> > feature if we had it.
> >
> > 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.
> >
>
> Sure, but whose to say that after synchronous wal shipping is "finished" it
> wont need a serious re-write due to new needs from the hot standby feature. I
> think going either way carries some risk.

The simplest form of synchronous wal shipping would not even need
postgresql running on slave, just a small daemon which reports when wal
blocks are a) received and b) synced to disk.

This setup would just guarantee "no data loss on single machine
failure". form there on you could add various features, including
support for both switchover and failover, async replication to multiple
slaves, etc.

the only thing that needs anything additional from slave wal-receiving
daemon is when you want the kind of wal-sync which would guarantee that
read-only query on slave issued after commit returns from master sees
latest data. for this kinds of guarantees you need at least feedback
about wal-replay, but possibly also shared transaction numbers and
shared snapshots, to be sure that OLTP type queries see the latest and
OLAP queries are not denied seeing VACUUMED on master.

--------------
Hannu