On Fri, 2009-02-27 at 12:21 -0800, Joshua D. Drake wrote:
> On Fri, 2009-02-27 at 22:17 +0200, Hannu Krosing wrote:
>
> > > Well VLDB is like 2% of what we need. If the above will remove all the
> > > B.S. currently associated with actually doing PITR (rsync, scp, nfs,
> > > pg_standby pick your poison) then I am all for it.
> >
> > If you use walmgr.py, then all you need is writing a conf file and
> > making sure that ssh and rsync work.
> >
> > Actually the best way to do Sync Rep would have been to just move to C
> > what walmgr.py does. That the patch could have started off from a
> > well-tested foundation.
> >
>
> For sync?
For everything up to starting sync.
It somehow feels like current patch concentrated mainly on doing the
sync part and the need to get also existing stete over automatically
became as an afterthought. That's why I'm proposing to start (at least
conceptually) from an existing, fully automated and working solution.
Currently walmgr.py is doing everything from setting up replica to
getting up-to-last-second changes to slave's disk.
> > > Log shipping should be:
> > >
> > > I am master, my slave is here.
> > > I am slave, I understand my master is here.
> > > Here is our mutual authentication love token.
> > > Let congress begin.
> > >
> > > Anything more and we are being difficult for the sake of being
> > > difficult.
> >
> > Actually I'd leave out the first line, and start with just
> >
> > - I am slave, my master accepts me, start replicationg
> >
>
> Heh fair enough.
>
> > So there could be several slaves, of both hot standby postgresql,
> > wal-file-store and store-and-forward-to-many types.
>
> That should be optional not the default.
Of course. One slave is a sub-case of "any number of slaves" :)
But doing 1-1 replica _only_ would make us laughing stock for everybody
else.
--
Hannu Krosing http://www.2ndQuadrant.com
PostgreSQL Scalability and Availability Services, Consulting and Training