Thread

1. Re: SSI patch version 14

   Kevin Grittner <kevin.grittner@wicourts.gov> — 2011-02-08T08:43:06Z

   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
   
   

2. Re: SSI patch version 14

   Heikki Linnakangas <heikki.linnakangas@enterprisedb.com> — 2011-02-08T09:25:34Z

   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
   
   

3. Re: SSI patch version 14

   Bruce Momjian <bruce@momjian.us> — 2011-02-08T12:23:55Z

   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@momjian.us>        http://momjian.us
     EnterpriseDB                             http://enterprisedb.com
   
     + It's impossible for everything to be true. +
   
   

4. Re: SSI patch version 14

   Dan Ports <drkp@csail.mit.edu> — 2011-02-08T15:40:01Z

   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/
   
   

5. Re: SSI patch version 14

   Kevin Grittner <kevin.grittner@wicourts.gov> — 2011-02-08T15:50:05Z

   Dan Ports <drkp@csail.mit.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
   
   

6. Re: SSI patch version 14

   Heikki Linnakangas <heikki.linnakangas@enterprisedb.com> — 2011-02-08T16:16:43Z

   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