Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1jJAOV-0000eu-Ug for pgsql-hackers@arkaria.postgresql.org; Tue, 31 Mar 2020 06:29:03 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1jJAOU-0003L7-DP for pgsql-hackers@arkaria.postgresql.org; Tue, 31 Mar 2020 06:29:02 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1jJAOU-0003L0-6k for pgsql-hackers@lists.postgresql.org; Tue, 31 Mar 2020 06:29:02 +0000 Received: from mail-pj1-x1041.google.com ([2607:f8b0:4864:20::1041]) by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1jJAOR-0006GA-8g for pgsql-hackers@postgresql.org; Tue, 31 Mar 2020 06:29:00 +0000 Received: by mail-pj1-x1041.google.com with SMTP id kx8so642125pjb.5 for ; Mon, 30 Mar 2020 23:28:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=leadboat.com; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=h8wMTvfnR/FMpRwDC9aDKpMnioSK17J1n5GsEDzoxpE=; b=YgX3AGDbDhP0Vrhhss51kTr00cBUpVM+3b2HOlk250D4QRll3hocCz8jGtgJLaE4RO eU33L5MQs+UJSm1cT6mOJlboQAYt8Nfiz9ueOofbriaJfCkcTmCdmarUuX3k9ZcyLJPq IxR4qdwDvzvDnQt6QcJscU54Ulqq1GBXx3rGA= 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:references :mime-version:content-disposition:in-reply-to:user-agent; bh=h8wMTvfnR/FMpRwDC9aDKpMnioSK17J1n5GsEDzoxpE=; b=meqrOCKQLy/sbsnjxeIt0gvJXBKV6A2GaF8xvMhoFwR5ihd6Lyn1X5b+zG9PNLhI1C riRAhOdDRib/trXphrTxDNFDEeZwA3+V1J9VdWM8jZhVJHIuijtiidWE8RUOS9+rSZ03 Ra7P1KCp4ru3aI8s8NkeFjyOLYpHSl6RR46QeQu+kPAE6QsgYVnsuX1YuSXFOekUEQ/v bGLLvgD3qaPbf3B+dA1vUHVO/PluhSEk4DPir0PQ9fFv0B1dxFUFrQGwtBGLGlys3fnX VQYUETNBplHmAmAWqohb6PNquQSdq1h36OcKpRXHNvSg6kjdgPX2Zf4UqtKXbwYXKt8A EKNg== X-Gm-Message-State: AGi0Pua3gEt5FX/YcOlXm/lr/mUzI5iUVsIIdnQVO4JqParIrArxpZO/ +/9qn1FhWMhJ6V5b+ciQwTbDqw== X-Google-Smtp-Source: APiQypLZFR+9vgKtTLcj8AlSJw30bnWk/HOUGj0XccCVctHZ1cXJ27/QYVSG+pD/pWO9CBd2O+ib4A== X-Received: by 2002:a17:90a:80ca:: with SMTP id k10mr2123580pjw.45.1585636138047; Mon, 30 Mar 2020 23:28:58 -0700 (PDT) Received: from rfd.leadboat.com (108-233-125-46.lightspeed.sntcca.sbcglobal.net. [108.233.125.46]) by smtp.gmail.com with ESMTPSA id x70sm6271710pfc.21.2020.03.30.23.28.56 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 30 Mar 2020 23:28:56 -0700 (PDT) Date: Mon, 30 Mar 2020 23:28:54 -0700 From: Noah Misch To: Michael Paquier Cc: Kyotaro Horiguchi , robertmhaas@gmail.com, pgsql-hackers@postgresql.org, 9erthalion6@gmail.com, andrew.dunstan@2ndquadrant.com, hlinnaka@iki.fi Subject: Re: [HACKERS] WAL logging problem in 9.4.3? Message-ID: <20200331062854.GC3354091@rfd.leadboat.com> References: <20200316034647.GA1121601@rfd.leadboat.com> <20200321190127.GA1763544@rfd.leadboat.com> <20200321224920.GB1763544@rfd.leadboat.com> <20200323.172027.2270553329883636814.horikyota.ntt@gmail.com> <20200330044101.GA2324620@rfd.leadboat.com> <20200330074300.GD43995@paquier.xyz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200330074300.GD43995@paquier.xyz> User-Agent: Mutt/1.5.24 (2015-08-30) List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk On Mon, Mar 30, 2020 at 04:43:00PM +0900, Michael Paquier wrote: > On Sun, Mar 29, 2020 at 09:41:01PM -0700, Noah Misch wrote: > > I think attached v41nm is ready for commit. Would anyone like to vote against > > back-patching this? It's hard to justify lack of back-patch for a data-loss > > bug, but this is atypically invasive. (I'm repeating the question, since some > > folks missed my 2020-02-18 question.) Otherwise, I'll push this on Saturday. > > The invasiveness of the patch is a concern. Have you considered a > different strategy? For example, we are soon going to be in beta for > 13, so you could consider committing the patch only on HEAD first. > If there are issues to take care of, you can then leverage the beta > testing to address any issues found. Finally, once some dust has > settled on the concept and we have gained enough confidence, we could > consider a back-patch. No. Does anyone favor this proposal more than back-patching normally?