Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1itHoP-0000f1-3M for pgsql-hackers@arkaria.postgresql.org; Sun, 19 Jan 2020 21:08:49 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1itHoN-0004ra-JG for pgsql-hackers@arkaria.postgresql.org; Sun, 19 Jan 2020 21:08:47 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1itHoN-0004rT-0A for pgsql-hackers@lists.postgresql.org; Sun, 19 Jan 2020 21:08:47 +0000 Received: from mail-qv1-xf44.google.com ([2607:f8b0:4864:20::f44]) by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1itHoJ-0001Ch-SY for pgsql-hackers@postgresql.org; Sun, 19 Jan 2020 21:08:45 +0000 Received: by mail-qv1-xf44.google.com with SMTP id n8so13139415qvg.11 for ; Sun, 19 Jan 2020 13:08:43 -0800 (PST) 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=nO/7ZzN4zrFDPELKX5sviOFIWKuZE16k3ztLkPZIzDI=; b=OC8nGAL0alixB1qTPdluqZC+0N9fHXVSuMeA8HRsLWIjzobk0QorvpLc7xkOO3SbWL WubwPWYrxalcIoYN92uyO8srcOk7L8qm5IwTTCLYjGDpizIygvrKSh1oloiB82nJ2HCQ +3Q/100kY+Z82DlQJ+VsrHuqCNXfredmvbYAVJqn5Y930z2jw0eLgv3iG5JshnbGmNaa HJxVjBg3zHmwMnWVL2OMRVNzkf8GM3jK/evjq5LgjPXZS/uzGTIw+xuiRAQbtS7Ou0Nq 6tVPek7K7wtbuNwQ+Iuud1tIL7v5tkJDLpp7svknKFa8RKlr0hT1r1C3DK4pElXEbtam hAMw== 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=nO/7ZzN4zrFDPELKX5sviOFIWKuZE16k3ztLkPZIzDI=; b=WQMyEIdCJIG/XOBprCSlY8dhek5+uTNDFY5ISm+oBkg4okXDBEufPxVu3yBaKoKWGU 7HgNqpJH5tGJ/pLvTZ2vuR+djG5nLfbDiO4s0EJV4du+kT5JeJgOoLSDnbT6Q8n9P6Az OfPAU+/tUt8xxtBzFWeG6E4YY6dWikNu6yKfHE410zz0x+d0PjMuuGBoIw3X4y6jHQ1+ tLHk1jhVxymtAvOsFhjHZtyTUeOMsmc5QdP/xHbmFTUFF6A3/Cr0kxbk/bZFbwEhxeso G5k/hMxnqfdGBy7G3+/D5/FTaw0jTgt6QwbZOjg9gwjcyEYcWuf5kEiL824yCcy/JtLd cyew== X-Gm-Message-State: APjAAAWRuGSlKfbQk1WpsYFZ68FllpKHeA45lgVMllMbgrJmkg0P97sR AbOtgpCWaUf5v6MLK355YxIgnw== X-Google-Smtp-Source: APXvYqyFj2zDrZeUE7pRmxCiIwWloyTcrLYXlAJFRosOW7e/S73HdvQklBVOIb3e2TER4GN4IKdZ9Q== X-Received: by 2002:a0c:8605:: with SMTP id p5mr17684357qva.109.1579468122119; Sun, 19 Jan 2020 13:08:42 -0800 (PST) Received: from nimloth.alvh.no-ip.org ([172.98.67.27]) by smtp.gmail.com with ESMTPSA id a24sm14816668qkl.82.2020.01.19.13.08.40 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 19 Jan 2020 13:08:41 -0800 (PST) Received: by nimloth.alvh.no-ip.org (Postfix, from userid 1000) id ECF2730080C; Sun, 19 Jan 2020 18:08:37 -0300 (-03) Date: Sun, 19 Jan 2020 18:08:37 -0300 From: Alvaro Herrera To: Michael Paquier Cc: Alexander Korotkov , Alexey Kondratov , Liudmila Mantrova , Thomas Munro , Andrey Borodin , David Steele , Andres Freund , PostgreSQL-development , Dmitry Dolgov <9erthalion6@gmail.com>, vladimirlesk@yandex-team.ru, dsarafan@yandex-team.ru Subject: Re: [Patch] pg_rewind: options to use restore_command from recovery.conf or command line Message-ID: <20200119210837.GA1485@alvherre.pgsql> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20200119102416.GB7464@paquier.xyz> User-Agent: Mutt/1.10.1 (2018-07-13) List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk On 2020-Jan-19, Michael Paquier wrote: > So using WAL to tell about a WAL segment file is wrong, WALs is not a > term that actually exists. I agree. > So, in my opinion, it is fine to use "WAL file", "WAL segment" or even > "WAL segment file". Agreed with these three terms -- "WAL file" seems to be the most common, but the other two terms you suggest are just as good. > +use File::Glob ':bsd_glob'; > +use File::Path qw(remove_tree make_path); > +use File::Spec::Functions qw(catdir catfile); > Is this compatible with our minimum perl requirements for the TAP > tests? By and large, we just join elements with a slash "foo/bar" to create path names; no need for catdir or catfile, ISTM. I *think* :bsd_glob should be available in all the Perl versions we support, but I'm not sure that we really need it. We seem to do just fine with regular glob elsewhere. PostgresNode already uses File::Path's rmtree. Looking at its manual, maybe the safest bet is to change all that to remove_tree. Not sure about make_path. -- Álvaro Herrera https://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services