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

From Merlin Moncure
Subject Re: Core team statement on replication in PostgreSQL
Date
Msg-id b42b73150805291725j1f0ccacfl779e758847b7aa2@mail.gmail.com
Whole thread Raw
In response to Re: Core team statement on replication in PostgreSQL  ("Joshua D. Drake" <jd@commandprompt.com>)
List pgsql-hackers
On Thu, May 29, 2008 at 7:12 PM, Joshua D. Drake <jd@commandprompt.com> wrote:
> On Thu, 2008-05-29 at 19:02 -0400, Tom Lane wrote:
>>   I think we have nontrivial
>> work in front of us to build a simple, reliable, community-tested
>> log shipping solution; and it's not very sexy work either.  But it
>> needs to get done, and it really needs to get done first.  There's
>> no point in having read-only slave queries if you don't have a
>> trustworthy method of getting the data to them.
>
> O.k. I was with you until here. Log shipping ala pg_standby works fine
> now sans read-only slave. No, it isn't out of the box which I can see an
> argument for but it is certainly trustworthy. Or do you mean the
> synchronous part?

I disagree...setting up pg_standby is more complex than it really has
to be.   There are several examples in the archives of people getting
their standby solutions busted with partial wal files, etc.  I helped
beta test pg_standby and there are a few 'gotchas' in getting it set
up properly.

pg_standby is not the problem (although there are some odd things
about it), it's getting files from point a to point b.  It would be
nice to have 'pg_archive' which mirrors pg_standby and handles the
work on the client side for example.

While some of us can work magic with rsync, etc.  It would be nice to
get things running with few .conf settings and no external
dependencies.

merlin


pgsql-hackers by date:

Previous
From: Decibel!
Date:
Subject: Change lock requirements for adding a trigger
Next
From: Greg Smith
Date:
Subject: Re: Core team statement on replication in PostgreSQL