1. 11 Jun, 2007 1 commit
    • Tom Lane's avatar
      Support UPDATE/DELETE WHERE CURRENT OF cursor_name, per SQL standard. · 6808f1b1
      Tom Lane authored
      Along the way, allow FOR UPDATE in non-WITH-HOLD cursors; there may once
      have been a reason to disallow that, but it seems to work now, and it's
      really rather necessary if you want to select a row via a cursor and then
      update it in a concurrent-safe fashion.
      
      Original patch by Arul Shaji, rather heavily editorialized by Tom Lane.
      6808f1b1
  2. 27 Feb, 2007 1 commit
    • Tom Lane's avatar
      Get rid of the separate EState for subplans, and just let them share the · c7ff7663
      Tom Lane authored
      parent query's EState.  Now that there's a single flat rangetable for both
      the main plan and subplans, there's no need anymore for a separate EState,
      and removing it allows cleaning up some crufty code in nodeSubplan.c and
      nodeSubqueryscan.c.  Should be a tad faster too, although any difference
      will probably be hard to measure.  This is the last bit of subsidiary
      mop-up work from changing to a flat rangetable.
      c7ff7663
  3. 22 Feb, 2007 1 commit
    • Tom Lane's avatar
      Turn the rangetable used by the executor into a flat list, and avoid storing · eab6b8b2
      Tom Lane authored
      useless substructure for its RangeTblEntry nodes.  (I chose to keep using the
      same struct node type and just zero out the link fields for unneeded info,
      rather than making a separate ExecRangeTblEntry type --- it seemed too
      fragile to have two different rangetable representations.)
      
      Along the way, put subplans into a list in the toplevel PlannedStmt node,
      and have SubPlan nodes refer to them by list index instead of direct pointers.
      Vadim wanted to do that years ago, but I never understood what he was on about
      until now.  It makes things a *whole* lot more robust, because we can stop
      worrying about duplicate processing of subplans during expression tree
      traversals.  That's been a constant source of bugs, and it's finally gone.
      
      There are some consequent simplifications yet to be made, like not using
      a separate EState for subplans in the executor, but I'll tackle that later.
      eab6b8b2
  4. 20 Feb, 2007 1 commit
    • Tom Lane's avatar
      Remove the Query structure from the executor's API. This allows us to stop · 9cbd0c15
      Tom Lane authored
      storing mostly-redundant Query trees in prepared statements, portals, etc.
      To replace Query, a new node type called PlannedStmt is inserted by the
      planner at the top of a completed plan tree; this carries just the fields of
      Query that are still needed at runtime.  The statement lists kept in portals
      etc. now consist of intermixed PlannedStmt and bare utility-statement nodes
      --- no Query.  This incidentally allows us to remove some fields from Query
      and Plan nodes that shouldn't have been there in the first place.
      
      Still to do: simplify the execution-time range table; at the moment the
      range table passed to the executor still contains Query trees for subqueries.
      
      initdb forced due to change of stored rules.
      9cbd0c15
  5. 06 Feb, 2007 1 commit
  6. 02 Feb, 2007 1 commit
    • Tom Lane's avatar
      Repair failure to check that a table is still compatible with a previously · 5413eef8
      Tom Lane authored
      made query plan.  Use of ALTER COLUMN TYPE creates a hazard for cached
      query plans: they could contain Vars that claim a column has a different
      type than it now has.  Fix this by checking during plan startup that Vars
      at relation scan level match the current relation tuple descriptor.  Since
      at that point we already have at least AccessShareLock, we can be sure the
      column type will not change underneath us later in the query.  However,
      since a backend's locks do not conflict against itself, there is still a
      hole for an attacker to exploit: he could try to execute ALTER COLUMN TYPE
      while a query is in progress in the current backend.  Seal that hole by
      rejecting ALTER TABLE whenever the target relation is already open in
      the current backend.
      
      This is a significant security hole: not only can one trivially crash the
      backend, but with appropriate misuse of pass-by-reference datatypes it is
      possible to read out arbitrary locations in the server process's memory,
      which could allow retrieving database content the user should not be able
      to see.  Our thanks to Jeff Trout for the initial report.
      
      Security: CVE-2007-0556
      5413eef8
  7. 10 Jan, 2007 1 commit
    • Tom Lane's avatar
      Change the planner-to-executor API so that the planner tells the executor · a191a169
      Tom Lane authored
      which comparison operators to use for plan nodes involving tuple comparison
      (Agg, Group, Unique, SetOp).  Formerly the executor looked up the default
      equality operator for the datatype, which was really pretty shaky, since it's
      possible that the data being fed to the node is sorted according to some
      nondefault operator class that could have an incompatible idea of equality.
      The planner knows what it has sorted by and therefore can provide the right
      equality operator to use.  Also, this change moves a couple of catalog lookups
      out of the executor and into the planner, which should help startup time for
      pre-planned queries by some small amount.  Modify the planner to remove some
      other cavalier assumptions about always being able to use the default
      operators.  Also add "nulls first/last" info to the Plan node for a mergejoin
      --- neither the executor nor the planner can cope yet, but at least the API is
      in place.
      a191a169
  8. 05 Jan, 2007 1 commit
  9. 26 Dec, 2006 1 commit
    • Tom Lane's avatar
      Fix failure due to accessing an already-freed tuple descriptor in a plan · 0cbc5b1e
      Tom Lane authored
      involving HashAggregate over SubqueryScan (this is the known case, there
      may well be more).  The bug is only latent in releases before 8.2 since they
      didn't try to access tupletable slots' descriptors during ExecDropTupleTable.
      The least bogus fix seems to be to make subqueries share the parent query's
      memory context, so that tupdescs they create will have the same lifespan as
      those of the parent query.  There are comments in the code envisioning going
      even further by not having a separate child EState at all, but that will
      require rethinking executor access to range tables, which I don't want to
      tackle right now.  Per bug report from Jean-Pierre Pelletier.
      0cbc5b1e
  10. 04 Dec, 2006 1 commit
  11. 04 Oct, 2006 1 commit
  12. 12 Aug, 2006 1 commit
  13. 04 Aug, 2006 1 commit
    • Tom Lane's avatar
      Fix domain_in() bug exhibited by Darcy Buskermolen. The idea of an EState · c6848986
      Tom Lane authored
      that's shorter-lived than the expression state being evaluated in it really
      doesn't work :-( --- we end up with fn_extra caches getting deleted while
      still in use.  Rather than abandon the notion of caching expression state
      across domain_in calls altogether, I chose to make domain_in a bit cozier
      with ExprContext.  All we really need for evaluating variable-free
      expressions is an ExprContext, not an EState, so I invented the notion of a
      "standalone" ExprContext.  domain_in can prevent resource leakages by doing
      a ReScanExprContext on this rather than having to free it entirely; so we
      can make the ExprContext have the same lifespan (and particularly the same
      per_query memory context) as the expression state structs.
      c6848986
  14. 16 Jun, 2006 1 commit
    • Tom Lane's avatar
      Fix problems with cached tuple descriptors disappearing while still in use · 06e10abc
      Tom Lane authored
      by creating a reference-count mechanism, similar to what we did a long time
      ago for catcache entries.  The back branches have an ugly solution involving
      lots of extra copies, but this way is more efficient.  Reference counting is
      only applied to tupdescs that are actually in caches --- there seems no need
      to use it for tupdescs that are generated in the executor, since they'll go
      away during plan shutdown by virtue of being in the per-query memory context.
      Neil Conway and Tom Lane
      06e10abc
  15. 05 Mar, 2006 1 commit
  16. 28 Feb, 2006 1 commit
    • Tom Lane's avatar
      Extend the ExecInitNode API so that plan nodes receive a set of flag · 2c0ef977
      Tom Lane authored
      bits indicating which optional capabilities can actually be exercised
      at runtime.  This will allow Sort and Material nodes, and perhaps later
      other nodes, to avoid unnecessary overhead in common cases.
      This commit just adds the infrastructure and arranges to pass the correct
      flag values down to plan nodes; none of the actual optimizations are here
      yet.  I'm committing this separately in case anyone wants to measure the
      added overhead.  (It should be negligible.)
      
      Simon Riggs and Tom Lane
      2c0ef977
  17. 12 Jan, 2006 1 commit
    • Tom Lane's avatar
      Repair "Halloween problem" in EvalPlanQual: a tuple that's been inserted by · 25b9b1b0
      Tom Lane authored
      our own command (or more generally, xmin = our xact and cmin >= current
      command ID) should not be seen as good.  Else we may try to update rows
      we already updated.  This error was inserted last August while fixing the
      even bigger problem that the old coding wouldn't see *any* tuples inserted
      by our own transaction as good.  Per report from Euler Taveira de Oliveira.
      25b9b1b0
  18. 03 Dec, 2005 1 commit
    • Tom Lane's avatar
      Tweak indexscan machinery to avoid taking an AccessShareLock on an index · a98871b7
      Tom Lane authored
      if we already have a stronger lock due to the index's table being the
      update target table of the query.  Same optimization I applied earlier
      at the table level.  There doesn't seem to be much interest in the more
      radical idea of not locking indexes at all, so do what we can ...
      a98871b7
  19. 02 Dec, 2005 1 commit
  20. 23 Nov, 2005 1 commit
    • Tom Lane's avatar
      Get rid of ExecAssignResultTypeFromOuterPlan() and make all plan node types · 4dd2048a
      Tom Lane authored
      generate their output tuple descriptors from their target lists (ie, using
      ExecAssignResultTypeFromTL()).  We long ago fixed things so that all node
      types have minimally valid tlists, so there's no longer any good reason to
      have two different ways of doing it.  This change is needed to fix bug
      reported by Hayden James: the fix of 2005-11-03 to emit the correct column
      names after optimizing away a SubqueryScan node didn't work if the new
      top-level plan node used ExecAssignResultTypeFromOuterPlan to generate its
      tupdesc, since the next plan node down won't have the correct column labels.
      4dd2048a
  21. 15 Oct, 2005 1 commit
  22. 20 Aug, 2005 1 commit
    • Tom Lane's avatar
      Repair problems with VACUUM destroying t_ctid chains too soon, and with · f57e3f4c
      Tom Lane authored
      insufficient paranoia in code that follows t_ctid links.  (We must do both
      because even with VACUUM doing it properly, the intermediate state with
      a dangling t_ctid link is visible concurrently during lazy VACUUM, and
      could be seen afterwards if either type of VACUUM crashes partway through.)
      Also try to improve documentation about what's going on.  Patch is a bit
      bulky because passing the XMAX information around required changing the
      APIs of some low-level heapam.c routines, but it's not conceptually very
      complicated.  Per trouble report from Teodor and subsequent analysis.
      This needs to be back-patched, but I'll do that after 8.1 beta is out.
      f57e3f4c
  23. 16 Apr, 2005 1 commit
  24. 16 Mar, 2005 1 commit
    • Tom Lane's avatar
      Revise TupleTableSlot code to avoid unnecessary construction and disassembly · f97aebd1
      Tom Lane authored
      of tuples when passing data up through multiple plan nodes.  A slot can now
      hold either a normal "physical" HeapTuple, or a "virtual" tuple consisting
      of Datum/isnull arrays.  Upper plan levels can usually just copy the Datum
      arrays, avoiding heap_formtuple() and possible subsequent nocachegetattr()
      calls to extract the data again.  This work extends Atsushi Ogawa's earlier
      patch, which provided the key idea of adding Datum arrays to TupleTableSlots.
      (I believe however that something like this was foreseen way back in Berkeley
      days --- see the old comment on ExecProject.)  A test case involving many
      levels of join of fairly wide tables (about 80 columns altogether) showed
      about 3x overall speedup, though simple queries will probably not be
      helped very much.
      
      I have also duplicated some code in heaptuple.c in order to provide versions
      of heap_formtuple and friends that use "bool" arrays to indicate null
      attributes, instead of the old convention of "char" arrays containing either
      'n' or ' '.  This provides a better match to the convention used by
      ExecEvalExpr.  While I have not made a concerted effort to get rid of uses
      of the old routines, I think they should be deprecated and eventually removed.
      f97aebd1
  25. 14 Mar, 2005 1 commit
    • Tom Lane's avatar
      Avoid O(N^2) overhead in repeated nocachegetattr calls when columns of · a9b05bdc
      Tom Lane authored
      a tuple are being accessed via ExecEvalVar and the attcacheoff shortcut
      isn't usable (due to nulls and/or varlena columns).  To do this, cache
      Datums extracted from a tuple in the associated TupleTableSlot.
      Also some code cleanup in and around the TupleTable handling.
      Atsushi Ogawa with some kibitzing by Tom Lane.
      a9b05bdc
  26. 31 Dec, 2004 1 commit
    • PostgreSQL Daemon's avatar
      · 2ff50159
      PostgreSQL Daemon authored
      Tag appropriate files for rc3
      
      Also performed an initial run through of upgrading our Copyright date to
      extend to 2005 ... first run here was very simple ... change everything
      where: grep 1996-2004 && the word 'Copyright' ... scanned through the
      generated list with 'less' first, and after, to make sure that I only
      picked up the right entries ...
      2ff50159
  27. 07 Oct, 2004 1 commit
    • Tom Lane's avatar
      Fix problems with SQL functions returning rowtypes that have dropped · a8487e15
      Tom Lane authored
      columns.  The returned tuple needs to have appropriate NULL columns
      inserted so that it actually matches the declared rowtype.  It seemed
      convenient to use a JunkFilter for this, so I made some cleanups and
      simplifications in the JunkFilter code to allow it to support this
      additional functionality.  (That in turn exposed a latent bug in
      nodeAppend.c, which is that it was returning a tuple slot whose
      descriptor didn't match its data.)  Also, move check_sql_fn_retval
      out of pg_proc.c and into functions.c, where it seems to more naturally
      belong.
      a8487e15
  28. 13 Sep, 2004 1 commit
    • Tom Lane's avatar
      Redesign query-snapshot timing so that volatile functions in READ COMMITTED · b2c40712
      Tom Lane authored
      mode see a fresh snapshot for each command in the function, rather than
      using the latest interactive command's snapshot.  Also, suppress fresh
      snapshots as well as CommandCounterIncrement inside STABLE and IMMUTABLE
      functions, instead using the snapshot taken for the most closely nested
      regular query.  (This behavior is only sane for read-only functions, so
      the patch also enforces that such functions contain only SELECT commands.)
      As per my proposal of 6-Sep-2004; I note that I floated essentially the
      same proposal on 19-Jun-2002, but that discussion tailed off without any
      action.  Since 8.0 seems like the right place to be taking possibly
      nontrivial backwards compatibility hits, let's get it done now.
      b2c40712
  29. 29 Aug, 2004 2 commits
  30. 10 May, 2004 1 commit
    • Tom Lane's avatar
      Promote row expressions to full-fledged citizens of the expression syntax, · 2f63232d
      Tom Lane authored
      rather than allowing them only in a few special cases as before.  In
      particular you can now pass a ROW() construct to a function that accepts
      a rowtype parameter.  Internal generation of RowExprs fixes a number of
      corner cases that used to not work very well, such as referencing the
      whole-row result of a JOIN or subquery.  This represents a further step in
      the work I started a month or so back to make rowtype values into
      first-class citizens.
      2f63232d
  31. 01 Apr, 2004 1 commit
    • Tom Lane's avatar
      Replace TupleTableSlot convention for whole-row variables and function · 375369ac
      Tom Lane authored
      results with tuples as ordinary varlena Datums.  This commit does not
      in itself do much for us, except eliminate the horrid memory leak
      associated with evaluation of whole-row variables.  However, it lays the
      groundwork for allowing composite types as table columns, and perhaps
      some other useful features as well.  Per my proposal of a few days ago.
      375369ac
  32. 17 Mar, 2004 1 commit
    • Tom Lane's avatar
      Replace the switching function ExecEvalExpr() with a macro that jumps · c1352052
      Tom Lane authored
      directly to the appropriate per-node execution function, using a function
      pointer stored by ExecInitExpr.  This speeds things up by eliminating one
      level of function call.  The function-pointer technique also enables further
      small improvements such as only making one-time tests once (and then
      changing the function pointer).  Overall this seems to gain about 10%
      on evaluation of simple expressions, which isn't earthshaking but seems
      a worthwhile gain for a relatively small hack.  Per recent discussion
      on pghackers.
      c1352052
  33. 02 Mar, 2004 1 commit
  34. 22 Jan, 2004 1 commit
  35. 14 Jan, 2004 1 commit
    • Tom Lane's avatar
      Fix permission-checking bug reported by Tim Burgess 10-Feb-03 (this time · cfd7fb7e
      Tom Lane authored
      for sure...).  Rather than relying on the query context of a rangetable
      entry to identify what permissions it wants checked, store a full AclMode
      mask in each RTE, and check exactly those bits.  This allows an RTE
      specifying, say, INSERT privilege on a view to be copied into a derived
      UPDATE query without changing meaning.  Per recent discussion thread.
      initdb forced due to change of stored rule representation.
      cfd7fb7e
  36. 18 Dec, 2003 1 commit
  37. 29 Nov, 2003 1 commit
    • PostgreSQL Daemon's avatar
      · 55b11325
      PostgreSQL Daemon authored
      make sure the $Id tags are converted to $PostgreSQL as well ...
      55b11325
  38. 01 Oct, 2003 1 commit
    • Tom Lane's avatar
      Repair RI trigger visibility problems (this time for sure ;-)) per recent · 55d85f42
      Tom Lane authored
      discussion on pgsql-hackers: in READ COMMITTED mode we just have to force
      a QuerySnapshot update in the trigger, but in SERIALIZABLE mode we have
      to run the scan under a current snapshot and then complain if any rows
      would be updated/deleted that are not visible in the transaction snapshot.
      55d85f42
  39. 25 Sep, 2003 1 commit