1. 30 Dec, 2002 1 commit
  2. 05 Dec, 2002 1 commit
    • Tom Lane's avatar
      Phase 1 of read-only-plans project: cause executor state nodes to point · 1fd0c59e
      Tom Lane authored
      to plan nodes, not vice-versa.  All executor state nodes now inherit from
      struct PlanState.  Copying of plan trees has been simplified by not
      storing a list of SubPlans in Plan nodes (eliminating duplicate links).
      The executor still needs such a list, but it can build it during
      ExecutorStart since it has to scan the plan tree anyway.
      No initdb forced since no stored-on-disk structures changed, but you
      will need a full recompile because of node-numbering changes.
      1fd0c59e
  3. 04 Sep, 2002 1 commit
  4. 20 Jun, 2002 1 commit
  5. 21 May, 2002 1 commit
    • Tom Lane's avatar
      Remove global variable scanCommandId in favor of storing a command ID · 959e61e9
      Tom Lane authored
      in snapshots, per my proposal of a few days ago.  Also, tweak heapam.c
      routines (heap_insert, heap_update, heap_delete, heap_mark4update) to
      be passed the command ID to use, instead of doing GetCurrentCommandID.
      For catalog updates they'll still get passed current command ID, but
      for updates generated from the main executor they'll get passed the
      command ID saved in the snapshot the query is using.  This should fix
      some corner cases associated with functions and triggers that advance
      current command ID while an outer query is still in progress.
      959e61e9
  6. 14 Feb, 2002 1 commit
  7. 05 Nov, 2001 1 commit
  8. 25 Oct, 2001 1 commit
  9. 05 Oct, 2001 1 commit
    • Tom Lane's avatar
      Further cleanup of dynahash.c API, in pursuit of portability and · 8a52b893
      Tom Lane authored
      readability.  Bizarre '(long *) TRUE' return convention is gone,
      in favor of just raising an error internally in dynahash.c when
      we detect hashtable corruption.  HashTableWalk is gone, in favor
      of using hash_seq_search directly, since it had no hope of working
      with non-LONGALIGNable datatypes.  Simplify some other code that was
      made undesirably grotty by promixity to HashTableWalk.
      8a52b893
  10. 21 May, 2001 1 commit
    • Jan Wieck's avatar
      Enhancement of SPI to get access to portals · d27f363e
      Jan Wieck authored
      - New functions to create a portal using a prepared/saved
        SPI plan or lookup an existing portal by name.
      - Functions to fetch/move from/in portals. Results are placed
        in the usual SPI_processed and SPI_tuptable, so the entire
        set of utility functions can be used to gain attribute access.
      - Prepared/saved SPI plans now use their own memory context
        and SPI_freeplan(plan) can remove them.
      - Tuple result sets (SPI_tuptable) now uses it's own memory
        context and can be free'd by SPI_freetuptable(tuptab).
      
      Enhancement of PL/pgSQL
      
      - Uses generic named portals internally in FOR ... SELECT
        loops to avoid running out of memory on huge result sets.
      - Support for CURSOR and REFCURSOR syntax using the new SPI
        functionality. Cursors used internally only need no explicit
        transaction block. Refcursor variables can be used inside
        of explicit transaction block to pass cursors between main
        application and functions.
      
      
      Jan
      d27f363e
  11. 22 Mar, 2001 1 commit
  12. 27 Feb, 2001 1 commit
    • Tom Lane's avatar
      Tweak portal (cursor) code so that it will not call the executor again · 778a21ca
      Tom Lane authored
      when user does another FETCH after reaching end of data, or another
      FETCH backwards after reaching start.  This is needed because some plan
      nodes are not very robust about being called again after they've already
      returned NULL; for example, MergeJoin will crash in some states but not
      others.  While the ideal approach would be for them all to handle this
      correctly, it seems foolish to assume that no such bugs would creep in
      again once cleaned up.  Therefore, the most robust answer is to prevent
      the situation from arising at all.
      778a21ca
  13. 24 Jan, 2001 1 commit
  14. 28 Jun, 2000 1 commit
    • Tom Lane's avatar
      First phase of memory management rewrite (see backend/utils/mmgr/README · 1aebc361
      Tom Lane authored
      for details).  It doesn't really do that much yet, since there are no
      short-term memory contexts in the executor, but the infrastructure is
      in place and long-term contexts are handled reasonably.  A few long-
      standing bugs have been fixed, such as 'VACUUM; anything' in a single
      query string crashing.  Also, out-of-memory is now considered a
      recoverable ERROR, not FATAL.
      Eliminate a large amount of crufty, now-dead code in and around
      memory management.
      Fix problem with holding off SIGTRAP, SIGSEGV, etc in postmaster and
      backend startup.
      1aebc361
  15. 12 Apr, 2000 1 commit
  16. 18 Feb, 2000 1 commit
  17. 26 Jan, 2000 1 commit
    • Bruce Momjian's avatar
      Add: · 5c25d602
      Bruce Momjian authored
        * Portions Copyright (c) 1996-2000, PostgreSQL, Inc
      
      to all files copyright Regents of Berkeley.  Man, that's a lot of files.
      5c25d602
  18. 10 Dec, 1999 1 commit
  19. 23 Sep, 1999 1 commit
  20. 09 Sep, 1999 1 commit
  21. 15 Jul, 1999 2 commits
  22. 12 Jun, 1999 2 commits
    • Bruce Momjian's avatar
      Reversed out Massimo patch. · 0c3281ce
      Bruce Momjian authored
      0c3281ce
    • Bruce Momjian's avatar
      I don't like last minute patches before the final freeze, but I believe that · 603e153b
      Bruce Momjian authored
      this one could be useful for people experiencing out-of-memory crashes while
      executing queries which retrieve or use a very large number of tuples.
      
      The problem happens when storage is allocated for functions results used in
      a large query, for example:
      
        select upper(name) from big_table;
        select big_table.array[1] from big_table;
        select count(upper(name)) from big_table;
      
      This patch is a dirty hack that fixes the out-of-memory problem for the most
      common cases, like the above ones. It is not the final solution for the
      problem but it can work for some people, so I'm posting it.
      
      The patch should be safe because all changes are under #ifdef. Furthermore
      the feature can be enabled or disabled at runtime by the `free_tuple_memory'
      options in the pg_options file. The option is disabled by default and must
      be explicitly enabled at runtime to have any effect.
      
      To enable the patch add the follwing line to Makefile.custom:
      
      CUSTOM_COPT += -DFREE_TUPLE_MEMORY
      
      To enable the option at runtime add the following line to pg_option:
      
      free_tuple_memory=1
      
      Massimo
      603e153b
  23. 25 May, 1999 1 commit
  24. 13 Feb, 1999 1 commit
  25. 06 Feb, 1999 1 commit
  26. 01 Sep, 1998 1 commit
  27. 26 Feb, 1998 1 commit
  28. 24 Jan, 1998 1 commit
  29. 08 Sep, 1997 2 commits
  30. 07 Sep, 1997 1 commit
  31. 19 Aug, 1997 1 commit
  32. 04 Nov, 1996 1 commit
  33. 31 Oct, 1996 1 commit
  34. 28 Aug, 1996 1 commit
  35. 13 Aug, 1996 1 commit
  36. 09 Jul, 1996 1 commit