1. 26 1月, 2010 2 次提交
  2. 25 1月, 2010 3 次提交
    • T
      Apply Tcl_Init() to the "hold" interpreter created by pltcl. · e7dcfd05
      Tom Lane 提交于
      You might think this is unnecessary since that interpreter is never used
      to run code --- but it turns out that's wrong.  As of Tcl 8.5, the "clock"
      command (alone among builtin Tcl commands) is partially implemented by
      loaded-on-demand Tcl code, which means that it fails if there's not
      unknown-command support, and also that it's impossible to run it directly
      in a safe interpreter.  The way they get around the latter is that
      Tcl_CreateSlave() automatically sets up an alias command that forwards any
      execution of "clock" in a safe slave interpreter to its parent interpreter.
      Thus, when attempting to execute "clock" in trusted pltcl, the command
      actually executes in the "hold" interpreter, where it will fail if
      unknown-command support hasn't been introduced by sourcing the standard
      init.tcl script, which is done by Tcl_Init().  (This is a pretty dubious
      design decision on the Tcl boys' part, if you ask me ... but they didn't.)
      
      Back-patch all the way.  It's not clear that anyone would try to use ancient
      versions of pltcl with a recent Tcl, but it's not clear they wouldn't, either.
      Also add a regression test using "clock", in branches that have regression
      test support for pltcl.
      
      Per recent trouble report from Kyle Bateman.
      e7dcfd05
    • J
      Rewrite dblink_record_internal() and dblink_fetch() to use a tuplestore · 56cbb611
      Joe Conway 提交于
      (SFRM_Materialize mode) to return tuples. Since we don't return from the
      dblink function in tuplestore mode, release the PGresult with a PG_CATCH
      block on error. Also rearrange to share the same code to materialize the
      tuplestore. Patch by Takahiro Itagaki.
      56cbb611
    • T
      Fix assorted core dumps and Assert failures that could occur during · 875353b9
      Tom Lane 提交于
      AbortTransaction or AbortSubTransaction, when trying to clean up after an
      error that prevented (sub)transaction start from completing:
      * access to TopTransactionResourceOwner that might not exist
      * assert failure in AtEOXact_GUC, if AtStart_GUC not called yet
      * assert failure or core dump in AfterTriggerEndSubXact, if
        AfterTriggerBeginSubXact not called yet
      
      Per testing by injecting elog(ERROR) at successive steps in StartTransaction
      and StartSubTransaction.  It's not clear whether all of these cases could
      really occur in the field, but at least one of them is easily exposed by
      simple stress testing, as per my accidental discovery yesterday.
      875353b9
  3. 24 1月, 2010 4 次提交
  4. 23 1月, 2010 4 次提交
  5. 22 1月, 2010 5 次提交
  6. 21 1月, 2010 10 次提交
  7. 20 1月, 2010 12 次提交