Re: Batch replication ordering (was Re: [GENERAL] 32/64-bit
От | Ed L. |
---|---|
Тема | Re: Batch replication ordering (was Re: [GENERAL] 32/64-bit |
Дата | |
Msg-id | 200304110946.55282.pgsql@bluepolka.net обсуждение исходный текст |
Ответ на | Re: Batch replication ordering (was Re: [GENERAL] 32/64-bit (Jan Wieck <JanWieck@Yahoo.com>) |
Список | pgsql-general |
On Friday April 11 2003 5:48, Jan Wieck wrote: > Tom Lane wrote: > > "Ed L." <pgsql@bluepolka.net> writes: > > > I don't think so. Can you imagine a replication queue big enough to > > > that someone might not want to process it entirely in one > > > transaction? > > > > No, I can't. The bigger the queue is, the further behind you are, and > > the more you need to catch up; twiddling your thumbs for awhile gets > > progressively less attractive. > > That is absolutely sure in an asynchronous multi-master situation, where > "twiddling" only leads to conflicts ... not making your situation any > easier. > > But in a pure master slave situation? There I can imagine this. The context of my question is strictly master slave. > What I cannot imagine is why one would want to try to make batches any > other size than the original transaction. Committing smaller "chunks" of > the masters transactions at the slave side would allow a client there to > see an inconsistent snapshot - that is bad (tm). Committing bigger > groups contains the risk that the slave run's out of resources that the > master didn't need - not any better. To what slave resources are you referring? Ed
В списке pgsql-general по дате отправления: