Re: Re: [COMMITTERS] pgsql: Adjust OLDSERXID_MAX_PAGE based on BLCKSZ.

From: Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>
To: Kevin Grittner <Kevin(dot)Grittner(at)wicourts(dot)gov>
Cc: pgsql-hackers(at)postgresql(dot)org, rhaas(at)postgresql(dot)org
Subject: Re: Re: [COMMITTERS] pgsql: Adjust OLDSERXID_MAX_PAGE based on BLCKSZ.
Date: 2011-07-08 14:34:24
Message-ID: 4E171570.6020401@enterprisedb.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 08.07.2011 16:45, Kevin Grittner wrote:
> Heikki Linnakangas<heikki(dot)linnakangas(at)enterprisedb(dot)com> wrote:
>> On 08.07.2011 15:22, Kevin Grittner wrote:
>
>>> MaxTransactionId / OLDSERXID_ENTRIESPERPAGE
>>
>> Hmm, that seems more correct to me anyway. We are trying to
>> calculate which page xid MaxTransactionId would be stored on, if
>> the SLRU didn't have a size limit. You calculate that with simply
>> MaxTransactionId / OLDSERXID_ENTRIESPERPAGE.
>
> Good point. The old calculation was finding the page before the
> page which would contain the first out-of-bound entry. As long as
> these numbers are all powers of 2 that's the same, but (besides the
> overflow issue) it's not as clear.
>
> On the off chance that this saves someone any work, trivial patch
> attached.

There was still one warning left after that:

.\src\backend\storage\lmgr\predicate.c(770): warning C4146: unary minus
operator applied to unsigned type, result still unsigned

It's coming from this line:

> else if (diff < -((OLDSERXID_MAX_PAGE + 1) / 2))

I fixed that by adding a cast to int there, and committed.

--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Kohei KaiGai 2011-07-08 14:41:41 Re: [v9.2] Fix leaky-view problem, part 1
Previous Message Tom Lane 2011-07-08 14:29:03 Re: Re: [COMMITTERS] pgsql: Adjust OLDSERXID_MAX_PAGE based on BLCKSZ.