Re: Core team statement on replication in PostgreSQL

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Core team statement on replication in PostgreSQL
Дата
Msg-id 21771.1212106470@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Core team statement on replication in PostgreSQL  ("Joshua D. Drake" <jd@commandprompt.com>)
Ответы 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>)
Список 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 по дате отправления:

Предыдущее
От: Chris Browne
Дата:
Сообщение: Re: Core team statement on replication in PostgreSQL
Следующее
От: Decibel!
Дата:
Сообщение: Change lock requirements for adding a trigger