1. 22 Jan, 2009 1 commit
  2. 01 Jan, 2009 1 commit
  3. 30 Nov, 2008 1 commit
    • Tom Lane's avatar
      Clean up the API for DestReceiver objects by eliminating the assumption · c1f30733
      Tom Lane authored
      that a Portal is a useful and sufficient additional argument for
      CreateDestReceiver --- it just isn't, in most cases.  Instead formalize
      the approach of passing any needed parameters to the receiver separately.
      
      One unexpected benefit of this change is that we can declare typedef Portal
      in a less surprising location.
      
      This patch is just code rearrangement and doesn't change any functionality.
      I'll tackle the HOLD-cursor-vs-toast problem in a follow-on patch.
      c1f30733
  4. 19 Nov, 2008 1 commit
    • Tom Lane's avatar
      Some infrastructure changes for the upcoming auto-explain contrib module: · cd35e9d7
      Tom Lane authored
      * Refactor explain.c slightly to export a convenient-to-use subroutine
      for printing EXPLAIN results.
      
      * Provide hooks for plugins to get control at ExecutorStart and ExecutorEnd
      as well as ExecutorRun.
      
      * Add some minimal support for tracking the total runtime of ExecutorRun.
      This code won't actually do anything unless a plugin prods it to.
      
      * Change the API of the DefineCustomXXXVariable functions to allow nonzero
      "flags" to be specified for a custom GUC variable.  While at it, also make
      the "bootstrap" default value for custom GUCs be explicitly specified as a
      parameter to these functions.  This is to eliminate confusion over where the
      default comes from, as has been expressed in the past by some users of the
      custom-variable facility.
      
      * Refactor GUC code a bit to ensure that a custom variable gets initialized to
      something valid (like its default value) even if the placeholder value was
      invalid.
      cd35e9d7
  5. 16 Nov, 2008 1 commit
    • Tom Lane's avatar
      Modify UPDATE/DELETE WHERE CURRENT OF to use the FOR UPDATE infrastructure to · 18004101
      Tom Lane authored
      locate the target row, if the cursor was declared with FOR UPDATE or FOR
      SHARE.  This approach is more flexible and reliable than digging through the
      plan tree; for instance it can cope with join cursors.  But we still provide
      the old code for use with non-FOR-UPDATE cursors.  Per gripe from Robert Haas.
      18004101
  6. 15 Nov, 2008 1 commit
    • Tom Lane's avatar
      Make SELECT FOR UPDATE/SHARE work on inheritance trees, by having the plan · 0656ed3d
      Tom Lane authored
      return the tableoid as well as the ctid for any FOR UPDATE targets that
      have child tables.  All child tables are listed in the ExecRowMark list,
      but the executor just skips the ones that didn't produce the current row.
      
      Curiously, this longstanding restriction doesn't seem to have been documented
      anywhere; so no doc changes.
      0656ed3d
  7. 06 Nov, 2008 1 commit
  8. 31 Oct, 2008 1 commit
  9. 25 Aug, 2008 1 commit
  10. 08 Aug, 2008 1 commit
    • Tom Lane's avatar
      Install checks in executor startup to ensure that the tuples produced by an · 30fd8ec7
      Tom Lane authored
      INSERT or UPDATE will match the target table's current rowtype.  In pre-8.3
      releases inconsistency can arise with stale cached plans, as reported by
      Merlin Moncure.  (We patched the equivalent hazard on the SELECT side in Feb
      2007; I'm not sure why we thought there was no risk on the insertion side.)
      In 8.3 and HEAD this problem should be impossible due to plan cache
      invalidation management, but it seems prudent to make the check anyway.
      
      Back-patch as far as 8.0.  7.x versions lack ALTER COLUMN TYPE, so there
      seems no way to abuse a stale plan comparably.
      30fd8ec7
  11. 26 Jul, 2008 1 commit
    • Tom Lane's avatar
      As noted by Andrew Gierth, there's really no need any more to force a junk · a77eaa6a
      Tom Lane authored
      filter to be used when INSERT or SELECT INTO has a plan that returns raw
      disk tuples.  The virtual-tuple-slot optimizations that were put in place
      awhile ago mean that ExecInsert has to do ExecMaterializeSlot, and that
      already copies the tuple if it's raw (and does so more efficiently than
      a junk filter, too).  So get rid of that logic.  This in turn means that
      we can throw away ExecMayReturnRawTuples, which wasn't used for any other
      purpose, and was always a kluge anyway.
      
      In passing, move a couple of SELECT-INTO-specific fields out of EState
      and into the private state of the SELECT INTO DestReceiver, as was foreseen
      in an old comment there.  Also make intorel_receive use ExecMaterializeSlot
      not ExecCopySlotTuple, for consistency with ExecInsert and to possibly save
      a tuple copy step in some cases.
      a77eaa6a
  12. 18 Jul, 2008 1 commit
  13. 12 May, 2008 2 commits
    • Alvaro Herrera's avatar
      Improve snapshot manager by keeping explicit track of snapshots. · 5da9da71
      Alvaro Herrera authored
      There are two ways to track a snapshot: there's the "registered" list, which
      is used for arbitrary long-lived snapshots; and there's the "active stack",
      which is used for the snapshot that is considered "active" at any time.
      This also allows users of snapshots to stop worrying about snapshot memory
      allocation and freeing, and about using PG_TRY blocks around ActiveSnapshot
      assignment.  This is all done automatically now.
      
      As a consequence, this allows us to reset MyProc->xmin when there are no
      more snapshots registered in the current backend, reducing the impact that
      long-running transactions have on VACUUM.
      5da9da71
    • Alvaro Herrera's avatar
      Restructure some header files a bit, in particular heapam.h, by removing some · f8c4d7db
      Alvaro Herrera authored
      unnecessary #include lines in it.  Also, move some tuple routine prototypes and
      macros to htup.h, which allows removal of heapam.h inclusion from some .c
      files.
      
      For this to work, a new header file access/sysattr.h needed to be created,
      initially containing attribute numbers of system columns, for pg_dump usage.
      
      While at it, make contrib ltree, intarray and hstore header files more
      consistent with our header style.
      f8c4d7db
  14. 09 May, 2008 1 commit
    • Tom Lane's avatar
      Change the rules for inherited CHECK constraints to be essentially the same · cd902b33
      Tom Lane authored
      as those for inherited columns; that is, it's no longer allowed for a child
      table to not have a check constraint matching one that exists on a parent.
      This satisfies the principle of least surprise (rows selected from the parent
      will always appear to meet its check constraints) and eliminates some
      longstanding bogosity in pg_dump, which formerly had to guess about whether
      check constraints were really inherited or not.
      
      The implementation involves adding conislocal and coninhcount columns to
      pg_constraint (paralleling attislocal and attinhcount in pg_attribute)
      and refactoring various ALTER TABLE actions to be more like those for
      columns.
      
      Alex Hunsaker, Nikhil Sontakke, Tom Lane
      cd902b33
  15. 21 Apr, 2008 1 commit
    • Tom Lane's avatar
      Fix a couple of places in execMain that erroneously assumed that SELECT FOR · f593f623
      Tom Lane authored
      UPDATE/SHARE couldn't occur as a subquery in a query with a non-SELECT
      top-level operation.  Symptoms included outright failure (as in report from
      Mark Mielke) and silently neglecting to take the requested row locks.
      
      Back-patch to 8.3, because the visible failure in the INSERT ... SELECT case
      is a regression from 8.2.  I'm a bit hesitant to back-patch further given the
      lack of field complaints.
      f593f623
  16. 28 Mar, 2008 1 commit
  17. 26 Mar, 2008 1 commit
  18. 07 Feb, 2008 1 commit
    • Tom Lane's avatar
      Fix CREATE TABLE ... LIKE ... INCLUDING INDEXES to not cause unwanted · b7fe5f70
      Tom Lane authored
      tablespace permissions failures when copying an index that is in the
      database's default tablespace.  A side-effect of the change is that explicitly
      specifying the default tablespace no longer triggers a permissions check;
      this is not how it was done in pre-8.3 releases but is argued to be more
      consistent.  Per bug #3921 from Andrew Gilligan.  (Note: I argued in the
      subsequent discussion that maybe LIKE shouldn't copy index tablespaces
      at all, but since no one indicated agreement with that idea, I've refrained
      from doing it.)
      b7fe5f70
  19. 01 Jan, 2008 1 commit
  20. 30 Nov, 2007 1 commit
    • Tom Lane's avatar
      Avoid incrementing the CommandCounter when CommandCounterIncrement is called · 895a94de
      Tom Lane authored
      but no database changes have been made since the last CommandCounterIncrement.
      This should result in a significant improvement in the number of "commands"
      that can typically be performed within a transaction before hitting the 2^32
      CommandId size limit.  In particular this buys back (and more) the possible
      adverse consequences of my previous patch to fix plan caching behavior.
      
      The implementation requires tracking whether the current CommandCounter
      value has been "used" to mark any tuples.  CommandCounter values stored into
      snapshots are presumed not to be used for this purpose.  This requires some
      small executor changes, since the executor used to conflate the curcid of
      the snapshot it was using with the command ID to mark output tuples with.
      Separating these concepts allows some small simplifications in executor APIs.
      
      Something for the TODO list: look into having CommandCounterIncrement not do
      AcceptInvalidationMessages.  It seems fairly bogus to be doing it there,
      but exactly where to do it instead isn't clear, and I'm disinclined to mess
      with asynchronous behavior during late beta.
      895a94de
  21. 15 Nov, 2007 2 commits
  22. 20 Sep, 2007 1 commit
    • Tom Lane's avatar
      HOT updates. When we update a tuple without changing any of its indexed · 282d2a03
      Tom Lane authored
      columns, and the new version can be stored on the same heap page, we no longer
      generate extra index entries for the new version.  Instead, index searches
      follow the HOT-chain links to ensure they find the correct tuple version.
      
      In addition, this patch introduces the ability to "prune" dead tuples on a
      per-page basis, without having to do a complete VACUUM pass to recover space.
      VACUUM is still needed to clean up dead index entries, however.
      
      Pavan Deolasee, with help from a bunch of other people.
      282d2a03
  23. 07 Sep, 2007 1 commit
    • Tom Lane's avatar
      Don't take ProcArrayLock while exiting a transaction that has no XID; there is · 0a51e707
      Tom Lane authored
      no need for serialization against snapshot-taking because the xact doesn't
      affect anyone else's snapshot anyway.  Per discussion.  Also, move various
      info about the interlocking of transactions and snapshots out of code comments
      and into a hopefully-more-cohesive discussion in access/transam/README.
      
      Also, remove a couple of now-obsolete comments about having to force some WAL
      to be written to persuade RecordTransactionCommit to do its thing.
      0a51e707
  24. 15 Aug, 2007 1 commit
    • Tom Lane's avatar
      Arrange to cache a ResultRelInfo in the executor's EState for relations that · 817946bb
      Tom Lane authored
      are not one of the query's defined result relations, but nonetheless have
      triggers fired against them while the query is active.  This was formerly
      impossible but can now occur because of my recent patch to fix the firing
      order for RI triggers.  Caching a ResultRelInfo avoids duplicating work by
      repeatedly opening and closing the same relation, and also allows EXPLAIN
      ANALYZE to "see" and report on these extra triggers.  Use the same mechanism
      to cache open relations when firing deferred triggers at transaction shutdown;
      this replaces the former one-element-cache strategy used in that case, and
      should improve performance a bit when there are deferred triggers on a number
      of relations.
      817946bb
  25. 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
  26. 03 Jun, 2007 1 commit
    • Tom Lane's avatar
      Create a GUC parameter temp_tablespaces that allows selection of the · acfce502
      Tom Lane authored
      tablespace(s) in which to store temp tables and temporary files.  This is a
      list to allow spreading the load across multiple tablespaces (a random list
      element is chosen each time a temp object is to be created).  Temp files are
      not stored in per-database pgsql_tmp/ directories anymore, but per-tablespace
      directories.
      
      Jaime Casanova and Albert Cervera, with review by Bernd Helmle and Tom Lane.
      acfce502
  27. 27 Apr, 2007 1 commit
    • Tom Lane's avatar
      Modify processing of DECLARE CURSOR and EXPLAIN so that they can resolve the · bbbe825f
      Tom Lane authored
      types of unspecified parameters when submitted via extended query protocol.
      This worked in 8.2 but I had broken it during plancache changes.  DECLARE
      CURSOR is now treated almost exactly like a plain SELECT through parse
      analysis, rewrite, and planning; only just before sending to the executor
      do we divert it away to ProcessUtility.  This requires a special-case check
      in a number of places, but practically all of them were already special-casing
      SELECT INTO, so it's not too ugly.  (Maybe it would be a good idea to merge
      the two by treating IntoClause as a form of utility statement?  Not going to
      worry about that now, though.)  That approach doesn't work for EXPLAIN,
      however, so for that I punted and used a klugy solution of running parse
      analysis an extra time if under extended query protocol.
      bbbe825f
  28. 29 Mar, 2007 1 commit
  29. 25 Mar, 2007 1 commit
    • Tom Lane's avatar
      Clean up the representation of special snapshots by including a "method · e85a01df
      Tom Lane authored
      pointer" in every Snapshot struct.  This allows removal of the case-by-case
      tests in HeapTupleSatisfiesVisibility, which should make it a bit faster
      (I didn't try any performance tests though).  More importantly, we are no
      longer violating portable C practices by assuming that small integers are
      distinct from all pointer values, and HeapTupleSatisfiesDirty no longer
      has a non-reentrant API involving side-effects on a global variable.
      
      There were a couple of places calling HeapTupleSatisfiesXXX routines
      directly rather than through the HeapTupleSatisfiesVisibility macro.
      Since these places had to be changed anyway, I chose to make them go
      through the macro for uniformity.
      
      Along the way I renamed HeapTupleSatisfiesSnapshot to HeapTupleSatisfiesMVCC
      to emphasize that it's only used with MVCC-type snapshots.  I was sorely
      tempted to rename HeapTupleSatisfiesVisibility to HeapTupleSatisfiesSnapshot,
      but forebore for the moment to avoid confusion and reduce the likelihood that
      this patch breaks some of the pending patches.  Might want to reconsider
      doing that later.
      e85a01df
  30. 06 Mar, 2007 1 commit
  31. 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
  32. 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
  33. 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
  34. 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
  35. 25 Jan, 2007 2 commits
  36. 05 Jan, 2007 1 commit
  37. 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