Received: from malur.postgresql.org ([2a02:16a8:dc51::56]) by arkaria.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.89) (envelope-from ) id 1fZ1tJ-00044g-1d for pgsql-hackers@arkaria.postgresql.org; Fri, 29 Jun 2018 22:29:21 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1fZ1tE-0006H1-KZ for pgsql-hackers@arkaria.postgresql.org; Fri, 29 Jun 2018 22:29:16 +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.89) (envelope-from ) id 1fZ1tE-0006Gu-Ac for pgsql-hackers@lists.postgresql.org; Fri, 29 Jun 2018 22:29:16 +0000 Received: from mail-qt0-x241.google.com ([2607:f8b0:400d:c0d::241]) by magus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1fZ1tA-00018A-0b for pgsql-hackers@lists.postgresql.org; Fri, 29 Jun 2018 22:29:15 +0000 Received: by mail-qt0-x241.google.com with SMTP id y31-v6so9246540qty.9 for ; Fri, 29 Jun 2018 15:29:11 -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=Qrox9zOdc4Py+VCDc2N0/s//7FCHGA195UVkbyVZ1jo=; b=TE+TK1jpc48od80V1Gj4oFOKdY2hoANL+anRHqONAtCAjgCbXZNRHGR0BWe/E6F/vw IgDwirXSnhXeoot830VhAHE+cVdMWmKXNLOGw3uwMPIqI5cvYvcTcH81dTozuW22Xk3c P79HfCKZvz1HJ1+q4jscBXJjGhmsxv/ZQL6HCFZ3b1mfTBm1LWH58hy/wJmQIlTsnQMa w5/qjKR6llHzmBskiFOYiS8HOzSb9iYlGrlFtQKMGj12ZdD5vjNVODzlg6coK8h0KvEz NETA0LCWP8r0AMBDWFSN6tMwkBxYJrW1VsEJ853CWC9t+tZzv/+hZFEdHgdq1Gc6owtD wS8g== 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=Qrox9zOdc4Py+VCDc2N0/s//7FCHGA195UVkbyVZ1jo=; b=ZZqjCliR9kMOa5awnU7j9mrUZP/0vn+gEaB/in9bilIZbXJG2QVnFQacihgoyZtKSU W832OiPv4oKhfYR/ZiOkByqgzHfrBz31JrSx8zW8yuSxRSGCKcu90wCsz2xiRN0w5jrv l7Mpfr8jT1G4KuhxAjbTzDPIORFpp9gMMBveMgyiqQAqq231/mAgjkJPA/R93CQKxuVg 9QPLlJrE6FmzFPvEbArVjyJ9IawRNE31TCNva5+tkqNHjmmH+ZPubq1KgQXwVs04aVKs q2FwJA3+wG3wKioG23L8lMUTRTqMkg/b2jUBeuFF8NfhjtiS4CoeLyxCbWH9yAeZG79+ CTmw== X-Gm-Message-State: APt69E2E9iUE/CXVwslG8F78u2mXSqhA8oIu6EROgXkR1h+kifMBWb62 Fv4jozBkBPGWnc5isZY9+HSwvmRlvd3nbM+wwiLnoS5ltDmFAEKBKH4urLyvL/YIF/sstaX4jFT NjRc9xzzKVWirNIGrrORzb7LKYkjfvFV82QrwKNduM9+m7mmuw7LUsDUAdsctPjAAUAqNLC9Hu2 4fn7DpsCA82RA= X-Google-Smtp-Source: AAOMgpeQztNFGDCchHYMzyBQ5yYfZVl9cZLmx0Y8aFvoNoMon5YZppChR+4IG5GAQTbwhqDYbM7Mbg== X-Received: by 2002:aed:3e50:: with SMTP id m16-v6mr15646901qtf.214.1530311349200; Fri, 29 Jun 2018 15:29:09 -0700 (PDT) Received: from alvin.alvh.no-ip.org ([190.121.29.3]) by smtp.gmail.com with ESMTPSA id j89-v6sm7119918qtb.14.2018.06.29.15.29.08 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Fri, 29 Jun 2018 15:29:08 -0700 (PDT) Received: by alvin.alvh.no-ip.org (Postfix, from userid 1000) id DE4A5110F; Fri, 29 Jun 2018 18:29:06 -0400 (-04) Date: Fri, 29 Jun 2018 18:29:06 -0400 From: Alvaro Herrera To: Tom Lane Cc: pgsql-hackers@lists.postgresql.org, 2q-andrew@alvin.alvh.no-ip.org Subject: Re: pgsql: Fix "base" snapshot handling in logical decoding Message-ID: <20180629222906.w5hqjgclmtk76v5i@alvherre.pgsql> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <26020.1530244390@sss.pgh.pa.us> User-Agent: NeoMutt/20170306-137-4415bd-dirty (1.8.0) List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk On 2018-Jun-28, Tom Lane wrote: > Alvaro Herrera writes: > > Fix "base" snapshot handling in logical decoding > > According to buildfarm member friarbird, and as confirmed here, > the contrib/test_decoding/specs/oldest_xmin.spec test added by this > commit fails under CLOBBER_CACHE_ALWAYS. Hm. Running this test under CLOBBER_CACHE_ALWAYS I see that the VACUUM FULL step takes 31 seconds (and the test succeeds). This is not top-of-the-line hardware by a long shot (Intel(R) Core(TM) i7-4600U CPU @ 2.10GHz) but I can believe that the other machines are slower or busier. Or there might be a completely different explanation ... -- Álvaro Herrera https://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services