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

From Tom Lane
Subject Re: Core team statement on replication in PostgreSQL
Date
Msg-id 21771.1212106470@sss.pgh.pa.us
Whole thread Raw
In response to Re: Core team statement on replication in PostgreSQL  ("Joshua D. Drake" <jd@commandprompt.com>)
Responses Re: Core team statement on replication in PostgreSQL  (Aidan Van Dyk <aidan@highrise.ca>)
Re: Core team statement on replication in PostgreSQL  ("Joshua D. Drake" <jd@commandprompt.com>)
List pgsql-hackers
"Joshua D. Drake" <jd@commandprompt.com> writes:
> I think maybe my actual argument isn't coming through. What I am arguing
> for is not shipping XY without Z. That is all. (and no, I don't think we
> should hold up 8.4).

So we should keep all the work out of the tree until every part is done?
No thanks; especially not when there is a perfectly respectable use-case
for parts X and Y alone (whether it suits *your* uses or not).

>> 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?

How much testing has pg_standby really gotten?  Some, sure, but it's a
contrib module that wasn't even there before 8.3.  Even ignoring the lag
issue, I wouldn't trust it a whole lot if I were a DBA responsible for
valuable data.  As much as some folk would like to think that contrib
is mainstream, it's not really in the same league as far as testing
coverage goes.
        regards, tom lane


pgsql-hackers by date:

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