Re: SSI patch version 14

Heikki Linnakangas wrote:

> Ok, committed.

I see that at least three BuildFarm critters don't have UINT64_MAX
defined. Not sure why coypu is running out of connections.

-Kevin

On 08.02.2011 10:43, Kevin Grittner wrote:
> Heikki Linnakangas wrote:
>
>> Ok, committed.
>
> I see that at least three BuildFarm critters don't have UINT64_MAX
> defined.

I guess we'll have to just #define it ourselves. Or could we just pick
another magic value, do we actually rely on InvalidSerCommitSeqno being
higher than all other values anywhere?

> Not sure why coypu is running out of connections.

Hmm, it seems to choose a smaller max_connections value now, 20 instead
of 30. Looks like our shared memory usage went up by just enough to pass
that threshold.

Looks like our shared memory footprint grew by about 2MB with default
configuration, from 37MB to 39MB. That's quite significant. Should we
dial down the default of max_predicate_locks_per_transaction? Or tweak
the sizing of the hash tables somehow?

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

Kevin Grittner wrote:
> Heikki Linnakangas wrote:
>
> > Ok, committed.
>
> I see that at least three BuildFarm critters don't have UINT64_MAX
> defined. Not sure why coypu is running out of connections.

Yes, I am seeing that failures here too on my BSD machine.

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ It's impossible for everything to be true. +

On Tue, Feb 08, 2011 at 11:25:34AM +0200, Heikki Linnakangas wrote:
> On 08.02.2011 10:43, Kevin Grittner wrote:
> > I see that at least three BuildFarm critters don't have UINT64_MAX
> > defined.
>
> I guess we'll have to just #define it ourselves. Or could we just pick
> another magic value, do we actually rely on InvalidSerCommitSeqno being
> higher than all other values anywhere?

As far as I know we don't specifically rely on that anywhere, and
indeed I did have it #defined to 1 at one point (with the other
constants adjusted to match) and I don't recall any problems. But given
that we most often use InvalidSerCommitSeqNo to mean "not committed
yet", it made more sense to set it to UINT64_MAX so that if a
comparison did sneak in it would do the right thing.

I did dust off a copy of the ANSI standard at the time, and it was
pretty explicit that UINT64_MAX is supposed to be defined in <stdint.h>.
But that may just be a C99 requirement (I didn't have an older copy of
the standard), and it's obviously no guarantee that it actually is
defined.

Dan

--
Dan R. K. Ports MIT CSAIL http://drkp.net/

Dan Ports <drkp(at)csail(dot)mit(dot)edu> wrote:
> On Tue, Feb 08, 2011 at 11:25:34AM +0200, Heikki Linnakangas
wrote:
>> On 08.02.2011 10:43, Kevin Grittner wrote:
>>> I see that at least three BuildFarm critters don't have
>>> UINT64_MAX defined.
>>
>> I guess we'll have to just #define it ourselves. Or could we just
>> pick another magic value, do we actually rely on
>> InvalidSerCommitSeqno being higher than all other values
>> anywhere?
>
> As far as I know we don't specifically rely on that anywhere, and
> indeed I did have it #defined to 1 at one point (with the other
> constants adjusted to match) and I don't recall any problems. But
> given that we most often use InvalidSerCommitSeqNo to mean "not
> committed yet", it made more sense to set it to UINT64_MAX so that
> if a comparison did sneak in it would do the right thing.
>
> I did dust off a copy of the ANSI standard at the time, and it was
> pretty explicit that UINT64_MAX is supposed to be defined in
> <stdint.h>. But that may just be a C99 requirement (I didn't have
> an older copy of the standard), and it's obviously no guarantee
> that it actually is defined.

Attached is something which will work. Whether people prefer this
or a definition of UINT64_MAX in some header file (if it's missing)
doesn't matter much to me.

At any rate, if someone commits this one-liner, three critters
should go back to green.

-Kevin

On 08.02.2011 17:50, Kevin Grittner wrote:
> Attached is something which will work. Whether people prefer this
> or a definition of UINT64_MAX in some header file (if it's missing)
> doesn't matter much to me.
>
> At any rate, if someone commits this one-liner, three critters
> should go back to green.

Thanks, committed.

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