1. 16 Sep, 2011 3 commits
    • Tom Lane's avatar
      Ensure generic plan gets used for a plpgsql expression with no parameters. · e6ed34f7
      Tom Lane authored
      Now that a NULL ParamListInfo pointer causes significantly different
      behavior in plancache.c, be sure to pass it that way when the expression
      is known not to reference any plpgsql variables.  Saves a few setup
      cycles anyway.
      e6ed34f7
    • Tom Lane's avatar
      gistendscan() forgot to free so->giststate. · 0a6cc285
      Tom Lane authored
      This oversight led to a massive memory leak --- upwards of 10KB per tuple
      --- during creation-time verification of an exclusion constraint based on a
      GIST index.  In most other scenarios it'd just be a leak of 10KB that would
      be recovered at end of query, so not too significant; though perhaps the
      leak would be noticeable in a situation where a GIST index was being used
      in a nestloop inner indexscan.  In any case, it's a real leak of long
      standing, so patch all supported branches.  Per report from Harald Fuchs.
      0a6cc285
    • Tom Lane's avatar
      Redesign the plancache mechanism for more flexibility and efficiency. · e6faf910
      Tom Lane authored
      Rewrite plancache.c so that a "cached plan" (which is rather a misnomer
      at this point) can support generation of custom, parameter-value-dependent
      plans, and can make an intelligent choice between using custom plans and
      the traditional generic-plan approach.  The specific choice algorithm
      implemented here can probably be improved in future, but this commit is
      all about getting the mechanism in place, not the policy.
      
      In addition, restructure the API to greatly reduce the amount of extraneous
      data copying needed.  The main compromise needed to make that possible was
      to split the initial creation of a CachedPlanSource into two steps.  It's
      worth noting in particular that SPI_saveplan is now deprecated in favor of
      SPI_keepplan, which accomplishes the same end result with zero data
      copying, and no need to then spend even more cycles throwing away the
      original SPIPlan.  The risk of long-term memory leaks while manipulating
      SPIPlans has also been greatly reduced.  Most of this improvement is based
      on use of the recently-added MemoryContextSetParent primitive.
      e6faf910
  2. 14 Sep, 2011 3 commits
  3. 13 Sep, 2011 2 commits
  4. 12 Sep, 2011 1 commit
    • Heikki Linnakangas's avatar
      In the final emptying phase of the new GiST buffering build, set the · 8caf6132
      Heikki Linnakangas authored
      queuedForEmptying flag correctly on buffer when adding it to the queue.
      Also, don't add buffer to the queue if it's there already. These were
      harmless oversights; failing to set the flag just means that a buffer might
      get added to the queue twice if more tuples are added to it (although that
      can't actually happen at this point because all the upper buffers have
      already been emptied), and having the same buffer twice in the emptying
      queue is harmless. But better be tidy.
      8caf6132
  5. 11 Sep, 2011 4 commits
  6. 10 Sep, 2011 6 commits
  7. 09 Sep, 2011 2 commits
    • Tom Lane's avatar
      Simplify handling of the timezone GUC by making initdb choose the default. · ca4af308
      Tom Lane authored
      We were doing some amazingly complicated things in order to avoid running
      the very expensive identify_system_timezone() procedure during GUC
      initialization.  But there is an obvious fix for that, which is to do it
      once during initdb and have initdb install the system-specific default into
      postgresql.conf, as it already does for most other GUC variables that need
      system-environment-dependent defaults.  This means that the timezone (and
      log_timezone) settings no longer have any magic behavior in the server.
      Per discussion.
      ca4af308
    • Tom Lane's avatar
      Move Timestamp/Interval typedefs and basic macros into datatype/timestamp.h. · a7801b62
      Tom Lane authored
      As per my recent proposal, this refactors things so that these typedefs and
      macros are available in a header that can be included in frontend-ish code.
      I also changed various headers that were undesirably including
      utils/timestamp.h to include datatype/timestamp.h instead.  Unsurprisingly,
      this showed that half the system was getting utils/timestamp.h by way of
      xlog.h.
      
      No actual code changes here, just header refactoring.
      a7801b62
  8. 08 Sep, 2011 6 commits
  9. 07 Sep, 2011 12 commits
  10. 06 Sep, 2011 1 commit