Skip to content
Snippets Groups Projects
  1. Jul 05, 2017
  2. Jul 03, 2017
    • Tom Lane's avatar
      Fix race condition in recovery/t/009_twophase.pl test. · 64767522
      Tom Lane authored
      Since reducing pg_ctl's reaction time in commit c61559ec, some
      slower buildfarm members have shown erratic failures in this test.
      The reason turns out to be that the test assumes synchronous
      replication (because it does not provide any lag time for a commit
      to replicate before shutting down the servers), but it had only
      enabled sync rep in one direction.  The observed symptoms correspond
      to failure to replicate the last committed transaction in the other
      direction, which can be expected to happen if the shutdown command
      is issued soon enough and we are providing no synchronous-commit
      guarantees.
      
      Fix that, and add a bit more paranoid state checking at the bottom
      of the script.
      
      Michael Paquier and myself
      
      Discussion: https://postgr.es/m/908.1498965681@sss.pgh.pa.us
      64767522
  3. Jul 02, 2017
    • Tom Lane's avatar
      Try to improve readability of recovery/t/009_twophase.pl test. · 4e15387d
      Tom Lane authored
      The original coding here was very confusing, because it named the
      two servers it set up "master" and "slave" even though it swapped
      their replication roles multiple times.  At any given point in the
      script it was very unobvious whether "$node_master" actually referred
      to the server named "master" or the other one.  Instead, pick arbitrary
      names for the two servers --- I used "london" and "paris" --- and
      distinguish those permanent names from the nonce references $cur_master
      and $cur_slave.  Add logging to help distinguish which is which at
      any given point.  Also, use distinct data and transaction names to
      make all the prepared transactions easily distinguishable in the
      postmaster logs.  (There was one place where we intentionally tested
      that the server could cope with re-use of a transaction name, but
      it seems like one place is sufficient for that purpose.)
      
      Also, add checks at the end to make sure that all the transactions
      that were supposed to be committed did survive.
      
      Discussion: https://postgr.es/m/28238.1499010855@sss.pgh.pa.us
      4e15387d
  4. May 18, 2017
  5. Apr 27, 2017
  6. Feb 21, 2017
Loading