1. 19 2月, 2010 7 次提交
    • H
      Don't use O_DIRECT when writing WAL files if archiving or streaming is · ad458cfe
      Heikki Linnakangas 提交于
      enabled. Bypassing the kernel cache is counter-productive in that case,
      because the archiver/walsender process will read from the WAL file
      soon after it's written, and if it's not cached the read will cause
      a physical read, eating I/O bandwidth available on the WAL drive.
      
      Also, walreceiver process does unaligned writes, so disable O_DIRECT
      in walreceiver process for that reason too.
      ad458cfe
    • H
      Forbid setval() during recovery. This prevents the PANIC reported by · 94f610b1
      Heikki Linnakangas 提交于
      Erik Rijkers. Patch by Andres Freund.
      94f610b1
    • I
      Fix STOP WAL LOCATION in backup history files no to return the next · 3230fd05
      Itagaki Takahiro 提交于
      segment of XLOG_BACKUP_END record even if the the record is placed
      at a segment boundary. Furthermore the previous implementation could
      return nonexistent segment file name when the boundary is in segments
      that has "FE" suffix; We never use segments with "FF" suffix.
      
      Backpatch to 8.0, where hot backup was introduced.
      
      Reported by Fujii Masao.
      3230fd05
    • P
      Translation updates for 9.0alpha4 · a39f02e3
      Peter Eisentraut 提交于
      a39f02e3
    • T
      Volatile-ize all five places where we expect a PG_TRY block to restore · a232f30f
      Tom Lane 提交于
      old memory context in plpython.  Before only one of them was marked
      volatile, but per report from Zdenek Kotala, some compilers do the
      wrong thing here.
      a232f30f
    • T
      Provide some rather hokey ways for EXPLAIN to print FieldStore and assignment · 858d1699
      Tom Lane 提交于
      ArrayRef expressions that are not in the immediate context of an INSERT or
      UPDATE targetlist.  Such cases never arise in stored rules, so ruleutils.c
      hadn't tried to handle them.  However, they do occur in the targetlists of
      plans derived from such statements, and now that EXPLAIN VERBOSE tries to
      print targetlists, we need some way to deal with the case.
      
      I chose to represent an assignment ArrayRef as "array[subscripts] := source",
      which is fairly reasonable and doesn't omit any information.  However,
      FieldStore is problematic because the planner will fold multiple assignments
      to fields of the same composite column into one FieldStore, resulting in a
      structure that is hard to understand at all, let alone display comprehensibly.
      So in that case I punted and just made it print the source expression(s).
      
      Backpatch to 8.4 --- the lack of functionality exists in older releases,
      but doesn't seem to be important for lack of anything that would call it.
      858d1699
    • T
      Fix ExecEvalArrayRef to pass down the old value of the array element or slice · 11d5ba97
      Tom Lane 提交于
      being assigned to, in case the expression to be assigned is a FieldStore that
      would need to modify that value.  The need for this was foreseen some time
      ago, but not implemented then because we did not have arrays of composites.
      Now we do, but the point evidently got overlooked in that patch.  Net result
      is that updating a field of an array element doesn't work right, as
      illustrated if you try the new regression test on an unpatched backend.
      Noted while experimenting with EXPLAIN VERBOSE, which has also got some issues
      in this area.
      
      Backpatch to 8.3, where arrays of composites were introduced.
      11d5ba97
  2. 18 2月, 2010 5 次提交
  3. 17 2月, 2010 20 次提交
  4. 16 2月, 2010 4 次提交
  5. 15 2月, 2010 4 次提交