On Tue, 2010-04-27 at 14:53 -0400, Tom Lane wrote:
> Hmm ... there's another point here, which is that the array size
> 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
In response to
pgsql-hackers by date
|Next:||From: Heikki Linnakangas||Date: 2010-04-27 19:40:32|
|Subject: Re: CP949 for EUC-KR?|
|Previous:||From: Alvaro Herrera||Date: 2010-04-27 19:20:30|
|Subject: Re: Re: [COMMITTERS] pgsql: Make
CheckRequiredParameterValues() depend upon correct|