Re: Batch replication ordering (was Re: [GENERAL] 32/64-bit - Mailing list pgsql-general

From Jan Wieck
Subject Re: Batch replication ordering (was Re: [GENERAL] 32/64-bit
Date
Msg-id 3E97128B.A0A711D4@Yahoo.com
Whole thread Raw
In response to 32/64-bit transaction IDs?  ("Ed L." <pgsql@bluepolka.net>)
Responses Re: Batch replication ordering (was Re: [GENERAL] 32/64-bit  ("Ed L." <pgsql@bluepolka.net>)
List 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 by date:

Previous
From:
Date:
Subject: Re: pgsql data file location
Next
From: Jonathan Bartlett
Date:
Subject: Re: Programms working on a PostgreSQL database written in