Re: testing HS/SR - 1 vs 2 performance - Mailing list pgsql-hackers

From Simon Riggs
Subject Re: testing HS/SR - 1 vs 2 performance
Date
Msg-id 1272396553.4161.8043.camel@ebony
Whole thread Raw
In response to Re: testing HS/SR - 1 vs 2 performance  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Tue, 2010-04-27 at 14:53 -0400, Tom Lane wrote:
> Hmm ... there's another point here, which is that the array size
> creates
> a hard maximum on the number of entries, whereas the hash table was a
> bit more forgiving.  What is the proof that the array won't overflow?
> The fact that the equivalent data structure on the master can't hold
> more than this many entries doesn't seem to me to prove that, because
> we will add intermediate not-observed XIDs to the array.

We know that not-observed xids have actually been allocated on the
primary. We log an assignment record every 64 subtransactions, so that
the peak size of the array is 65 xids per connection.

It's possible for xids to stay in the array for longer, in the event of
a FATAL error that doesn't log an abort record. We clean those up every
checkpoint, if they exist. The potential number of them is unbounded, so
making special allowance for them doesn't remove the theoretical risk.

-- Simon Riggs           www.2ndQuadrant.com



pgsql-hackers by date:

Previous
From: Alvaro Herrera
Date:
Subject: Re: Re: [COMMITTERS] pgsql: Make CheckRequiredParameterValues() depend upon correct
Next
From: Heikki Linnakangas
Date:
Subject: Re: CP949 for EUC-KR?