Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dRik4-0005jq-Bp for pgsql-hackers@arkaria.postgresql.org; Sun, 02 Jul 2017 17:33:04 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.84_2) (envelope-from ) id 1dRik3-0004yO-N2 for pgsql-hackers@arkaria.postgresql.org; Sun, 02 Jul 2017 17:33:03 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1dRik2-0004yC-2t for pgsql-hackers@postgresql.org; Sun, 02 Jul 2017 17:33:02 +0000 Received: from mail-qt0-x231.google.com ([2607:f8b0:400d:c0d::231]) by magus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.84_2) (envelope-from ) id 1dRijt-0001WB-Ah for pgsql-hackers@postgresql.org; Sun, 02 Jul 2017 17:33:01 +0000 Received: by mail-qt0-x231.google.com with SMTP id r30so129388446qtc.0 for ; Sun, 02 Jul 2017 10:32:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=2ndquadrant-com.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:mime-version:content-disposition :content-transfer-encoding:in-reply-to:user-agent; bh=iCmAAqO/87Dz47bC6vvizJiYOwkcdLo/QALoOWMCYVQ=; b=gU4eJ9EjvWF3eNHbUlc/6LCmK868GiAsjQ+DHKX1rxs2dIP8UiPy1TcSk8TVkorbJz HPcVqlN1jjef/VsxBkj1vJbTRPl+jnpv+BtUyVb4OLv+30l/zN7058HEX1knppHUQroA yTjrdiaQ0JCZkiF+7DklvtrSTHTggb5YuIfykyEpNSVxXbBUXBXLCKoQNGt0p8uU/kwS DJuR6fRs+gD2EorYgZsJYRuNOGEDS3RrZC39CiIx3Emas/RhBfzGesEIVWk44QGAbXYK g+Pv4DyISTl2i42iyDY5Dj/o5dJLCZf+9MMLQ8lG9ikv4Rm0xCbMg2JPNzhFwAtfCea+ Ldkw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:mime-version :content-disposition:content-transfer-encoding:in-reply-to :user-agent; bh=iCmAAqO/87Dz47bC6vvizJiYOwkcdLo/QALoOWMCYVQ=; b=NQtBl5QEql0ZSLdT8+XAgSAYpTpe83D7BAqLRDNL5K3G3PRLPjatc4u6+RAEpp9HrN r82zham7UcS1BhYen5hOw+0H5V61WuTXLDGkHYnWqYGgoTJi2gG6ROOyjEcSBRoLKsZY j1qc83tQF5rZoYTKmpAPIJjFf25Iru5J7/qRDro48CpOgy1/5Nhh5d5JkCPKh1qjyj2z qKNgXJ14UbG4Q11ck2+fOjrU+BTQO/pKB6JuM1MVPw4qSc3G4Hij0Nzb5AA1DUJgRNrz XqJyzR2EnBAImqFr+Llup7DuoenlRV2tMObfm/3Dm/477sQXi34NW+vy3Ci+c+wqCstE SFDQ== X-Gm-Message-State: AKS2vOwdI6aasucUimxXyp1ZSL/zb6cwTXEyz6KUJL7k4UQr8zt+eW3b cP5f9aOhrg8RtpVo15iOhrAObxFbdUB/jbMBp7xNs+jG0IKGz4PmfSbPrzXp3u1ve4cc9opnRw4 iFUfTaL0MdGOHXysfD9pjXfU5FcNktZ4VdiFg6lhfjGbMksm3CAxrwIET1Z7FhJ/iGwBEpg== X-Received: by 10.237.42.20 with SMTP id c20mr37296098qtd.74.1499016771062; Sun, 02 Jul 2017 10:32:51 -0700 (PDT) Received: from alvin.alvh.no-ip.org ([190.217.209.130]) by smtp.gmail.com with ESMTPSA id u76sm10412240qka.26.2017.07.02.10.32.49 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 02 Jul 2017 10:32:50 -0700 (PDT) Received: by alvin.alvh.no-ip.org (Postfix, from userid 1000) id C6F0F43B; Sun, 2 Jul 2017 13:32:43 -0400 (-04) Date: Sun, 2 Jul 2017 13:32:43 -0400 From: Alvaro Herrera To: Tom Lane Cc: pgsql-hackers@postgresql.org Subject: Re: Race-like failure in recovery/t/009_twophase.pl Message-ID: <20170702173243.n3egcibv4svzthak@alvherre.pgsql> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <28238.1499010855@sss.pgh.pa.us> User-Agent: NeoMutt/20170306-137-4415bd-dirty (1.8.0) List-Archive: List-Help: List-ID: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: X-Mailing-List: pgsql-hackers Precedence: bulk Sender: pgsql-hackers-owner@postgresql.org Tom Lane wrote: > I'd kind of like to fix it now, so I can reason in a less confused way > about the actual problem. OK, no objections here. > Last night I didn't have a clear idea of how > to make it better, but what I'm thinking this morning is: > > * Naming the underlying server objects "master" and "slave" is just > wrong, because the script makes them swap those roles repeatedly. > Better to choose neutral names, like "alice" and "bob" or "london" > and "paris". Check. > * We could simply make the test script refer directly to the appropriate > server at each step, ie s/node_master/node_london/ in relevant parts of > the script and s/node_slave/node_london/ elsewhere. Maybe that's the > best way, but there is some value in identifying commands as to whether > we're issuing them to the current master or the current slave. Plan B > might be to do > ($cur_master, $cur_slave) = ($node_paris, $node_london); > at the swap points and use those names where it seems clearer. Hmm, yeah, using role-based aliases seems like a good idea too. > * Some effort should be put into emitting text to the log showing > what's going on, eg print("Now london is master."); as appropriate. Check. Not "print" though; I think using note(" .. ") (from Test::More) is more appropriate. > * Another reason why I had the feeling of being lost in a maze of > twisty little passages all alike was the relentless sameness of the > commands being sent to the servers. There is no good reason for the > prepared transactions to be all alike; they should be all different > so that you can match up postmaster log entries to points in the > script. Check. -- Álvaro Herrera https://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers