Re: Batch replication ordering (was Re: [GENERAL] 32/64-bit transaction IDs?)
От | Tom Lane |
---|---|
Тема | Re: Batch replication ordering (was Re: [GENERAL] 32/64-bit transaction IDs?) |
Дата | |
Msg-id | 7109.1050012678@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Batch replication ordering (was Re: [GENERAL] 32/64-bit transaction IDs?) ("Ed L." <pgsql@bluepolka.net>) |
Ответы |
Re: Batch replication ordering (was Re: [GENERAL] 32/64-bit transaction IDs?)
|
Список | pgsql-general |
"Ed L." <pgsql@bluepolka.net> writes: > On Saturday March 22 2003 12:00, Tom Lane wrote: >> Note that all of a transaction's updates will become visible in the >> pending-update table simultaneously when it commits, so (as long as >> you grab batches in single SELECTs, or with a serializable transaction) >> there's no problems with partial transactions being applied by a batch. > If you grab everything in the queue with a single SELECT, this works. > Depending on the queue length, that's not always practical, and as noted > above, committed batches could result in partial transactions on the slave. > So the riddle is how to get a consistent but batchable replication order. You don't have to do anything special if you pull the contents of a batch in a single serializable transaction. I see no reason to think that using a serializable transaction is "hammering the master"; so you are asking for a solution to a non-problem. regards, tom lane
В списке pgsql-general по дате отправления: