Re: Batch replication ordering (was Re: [GENERAL] 32/64-bit
От | Jan Wieck |
---|---|
Тема | Re: Batch replication ordering (was Re: [GENERAL] 32/64-bit |
Дата | |
Msg-id | 3E97128B.A0A711D4@Yahoo.com обсуждение исходный текст |
Ответ на | 32/64-bit transaction IDs? ("Ed L." <pgsql@bluepolka.net>) |
Ответы |
Re: Batch replication ordering (was Re: [GENERAL] 32/64-bit
|
Список | pgsql-general |
"Ed L." wrote: > > On Friday April 11 2003 10:08, Jan Wieck wrote: > > Clearly a bug, but we had memory leaks that clear up at transaction end. > > That seems like yet another reason for constraining the size of a batch of > transactions. Er ... what? I said: What I cannot imagine is why one would want to try to make batches any other size than the original transaction. "the original transaction" - singular!!! Not a couple, few, maybe some, part, fraction or anything in between, above or below. Exactly ONE. > > > One of the "leaks" we still have: Constraint trigger queue. > > What is that about? Or if you don't want to re-explain, what would I search > for in the archive? If you have a deferred referential integrity constraint defined (one of the reasons why half of a transaction cannot work at all), where does the backend remember the ctid's and other information for the triggers to call at commit time? Jan -- #======================================================================# # It's easier to get forgiveness for being wrong than for being right. # # Let's break this rule - forgive me. # #================================================== JanWieck@Yahoo.com #
В списке pgsql-general по дате отправления: