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  ("Ed L." <pgsql@bluepolka.net>)
Список 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 по дате отправления:

Предыдущее
От:
Дата:
Сообщение: Re: pgsql data file location
Следующее
От: Jonathan Bartlett
Дата:
Сообщение: Re: Programms working on a PostgreSQL database written in