1. 01 9月, 2016 3 次提交
    • A
      Check for zero persistentTID in xlog record · 9b2eb416
      Ashwin Agrawal 提交于
      Refactor code to use common routine to fetch PT info for xlogging. Check can
      be easliy added at this common place to validate persistent info is
      available. Plus still add check during recovery for persistentTID zero. As
      with postgres upstream merges possible the function to populate persistent info is
      not called at all, so this check will not hit during xlog record construction
      but atleast gives clear clue during recovery.
      9b2eb416
    • A
      Skip persistent tables in VACUUM · 0cf6476d
      Ashwin Agrawal 提交于
      Vacuum lazy is harmless, but also no benefit to perform just extra work.
      Vacuum full could turn out dangerous as it has potential to move tuples
      around causing the TIDs for tuples to change, which violates its reference
      from gp_relation_node. In general persistent table has all frozen tuples
      so vacuum full is harmless too, but for example one scenario where it becomes
      dangerous is zero-page case due to failure after page extension but before
      page initialization. Also, since all the tuples in persistent table are
      frozen inserts, skip it from database age calculation.
      0cf6476d
    • A
      Add documentation for CREATE/ALTER/DROP PROTOCOL · 7f49de73
      Andreas Scherbaum 提交于
      Close: #1057
      Fix: #912
      7f49de73
  2. 31 8月, 2016 5 次提交
    • A
      Add Greenplum specific permissions to \du output · b223c5ef
      Andreas Scherbaum 提交于
      Closes: #1050
      Closes: #1028
      b223c5ef
    • K
      Fix postmaster reset failure on segment nodes with mirror configured · 1b02bd8f
      Kenan Yao 提交于
      If a QE crashes for reasons such as SIGSEGV, SIGKILL or PANIC, segment
      postmaster reset fails sometimes. The root cause is: primary segment
      postmaster would first tell child processes to exit, then start a filerep
      peer reset process to instruct mirror postmaster do reset; the filerep peer
      reset process would only exit when mirror postmaster finishes or fails the
      reset procedure; primary postmaster would wait for the termination
      of important processes such as AutoVacuum, BgWriter, CheckPoint, filerep peer
      reset process etc, before it resets share memory and restarts auxiliary
      processes; however, in some cases, primary postmaster would be stuck in filerep
      peer reset step, if mirror postmaster is hanging/waiting for some events;
      if this happens, filerep peer reset process would wait there until timeout(1 hour),
      and retry 10 times before reports failure to primary postmaster (so 10 hours in total);
      so the final result is primary postmaster takes 10 hours to report reset failure.
      
      This happens almost every time on mirror segment host machine with poor performance
      for reasons that: mirror postmaster would do similar reset procedure with
      primary postmaster, i.e, notify child processes to exit and wait their
      terminations and then restart auxiliary processes; filerep peer reset process
      would first connect to mirror postmaster to request a postmaster reset, then it would
      check the reset status of mirror every 10ms by connecting to mirror postmaster;
      so it can happen that filerep peer reset process keeps connecting mirror
      postmaster, which would lead to continuous dead_end backend processes forked,
      while at the same time mirror postmaster waits for the exit of all dead_end backend
      processes, so it is possible that the speed of generating new dead_end processes
      exceeds the exit speed, and hence mirror postmaster can never see the clearance of
      child processes. All in all, this can lead to hang issue and failure of postmaster reset.
      
      This issue exists for master postmaster reset as well on heavy workload circumstances.
      1b02bd8f
    • K
      Remove WalSendServerProc enum since it is never used · aa02fa06
      Kenan Yao 提交于
      aa02fa06
    • K
      Fix the postmaster reset failure on master node · 6b323078
      Kenan Yao 提交于
      If a QD crashes for reasons such as SIGSEGV, SIGKILL or PANIC,
      postmaster reset fails sometimes. The root cause is: postmaster
      would first tell child processes to exit, and then wait for the
      termination of important processes such as AutoVacuum, BgWriter,
      CheckPoint etc, before it resets share memory and restarts auxiliary
      processes; however, WAL writer process is missed in the waiting list,
      so it can happen that postmaster spawns StartupProcess and then notices
      the exit of WAL writer, so it tells StartupProcess to exit; then
      postmaster would notice the abnormal exit of StartupProcess in turn,
      and treats it as recovery failure, then call exit() itself. Thus, we end
      up with no postmaster process on master node at all.
      
      This happens almost everytime when master host machine has poor performance.
      6b323078
    • S
      Add new GUC to control Codegen Optimization level. · f160fa5a
      Shreedhar Hardikar 提交于
      Used when compiling generated code. EXPLAIN codegen also
      runs optimize with this optimize level, making it easier to see
      the features the compiler optimizes.
      f160fa5a
  3. 30 8月, 2016 1 次提交
  4. 29 8月, 2016 19 次提交
  5. 28 8月, 2016 1 次提交
  6. 26 8月, 2016 8 次提交
  7. 25 8月, 2016 3 次提交
    • H
    • H
      Reformat some GPDB-specific files. · 31b4c867
      Heikki Linnakangas 提交于
      Whitespace and comment fixes, to follow the usual project style.
      
      Remove duplicated function comments between the .h and .c files. Per the
      usual project convention, all explanations of a function and its arguments
      are in the .c file, and the .h file only contains the prototypes. There
      were some additional comments about the "sections" of the files that
      seemed useful, but were only in the .h files. I moved those to the .c
      files instead.
      31b4c867
    • H
      Change AO block checksum algorithm to match that of 4.3. · b2ba0062
      Heikki Linnakangas 提交于
      Turns out that commit 6c025b52 subtly
      changed the CRC calculation. The old crc32cFinish() inline function
      returned the final checksum, while the new FIN_CRC32C() macro modifies
      the variable in place. The old calls to crc32cFinish() discarded the
      return value, and were therefore in fact no-ops. That was surely not
      intentional, but it doesn't make any difference to the strength of
      the checksum, so it doesn't seem worth changing from previous releases.
      b2ba0062