Re: Replication identifiers, take 3

Поиск
Список
Период
Сортировка
От Jim Nasby
Тема Re: Replication identifiers, take 3
Дата
Msg-id 543054EA.50902@BlueTreble.com
обсуждение исходный текст
Ответ на Re: Replication identifiers, take 3  (Robert Haas <robertmhaas@gmail.com>)
Список pgsql-hackers
On 10/2/14, 7:28 AM, Robert Haas wrote:
> On Thu, Oct 2, 2014 at 4:49 AM, Heikki Linnakangas
> <hlinnakangas@vmware.com>  wrote:
>> >An origin column in the table itself helps tremendously to debug issues with
>> >the replication system. In many if not most scenarios, I think you'd want to
>> >have that extra column, even if it's not strictly required.
> I like a lot of what you wrote here, but I strongly disagree with this
> part.  A good replication solution shouldn't require changes to the
> objects being replicated.
I agree that asking users to modify objects is bad, but I also think that if you do have records coming into one table
frommultiple sources then you will need to know what system they originated on.
 

Maybe some sort of "hidden" column would work here? That means users don't need to modify anything (including anything
doingSELECT *), but the data is there.
 

As for space concerns I think the answer there is to somehow normalize the identifiers themselves. That has the added
benefitof allowing a rename of a source to propagate to all the data already replicated from that source.
 



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Jim Nasby
Дата:
Сообщение: Re: Log notice that checkpoint is to be written on shutdown
Следующее
От: Bruce Momjian
Дата:
Сообщение: Re: Aussie timezone database changes incoming