Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.80) (envelope-from ) id 1Yz5ak-0008Qh-2p for pgsql-hackers@arkaria.postgresql.org; Sun, 31 May 2015 15:56:02 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.80) (envelope-from ) id 1Yz5aj-0005lE-GU for pgsql-hackers@arkaria.postgresql.org; Sun, 31 May 2015 15:56:01 +0000 Received: from makus.postgresql.org ([2001:4800:1501:1::229]) by malur.postgresql.org with esmtps (TLS1.2:RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from ) id 1Yz5ag-0005kf-Ia; Sun, 31 May 2015 15:55:58 +0000 Received: from sss.pgh.pa.us ([66.207.139.130]) by makus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.84) (envelope-from ) id 1Yz5ad-0002lW-Um; Sun, 31 May 2015 15:55:57 +0000 Received: from sss1.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.pgh.pa.us (8.14.4/8.14.4) with ESMTP id t4VFtir4032434; Sun, 31 May 2015 11:55:44 -0400 From: Tom Lane To: Bruce Momjian cc: Michael Paquier , Andres Freund , Robert Haas , Stephen Frost , Magnus Hagander , "pgsql-hackers@postgresql.org" , pgsql-core Subject: Re: [CORE] postpone next week's release In-reply-to: <20150531140305.GD13697@momjian.us> References: <20150529223321.GB6535@alap3.anarazel.de> <12510.1432958887@sss.pgh.pa.us> <20150530154559.GA25053@momjian.us> <20150530204727.GJ13944@alap3.anarazel.de> <20150531024845.GB13697@momjian.us> <20150531135025.GC13697@momjian.us> <20150531140305.GD13697@momjian.us> Comments: In-reply-to Bruce Momjian message dated "Sun, 31 May 2015 10:03:05 -0400" Date: Sun, 31 May 2015 11:55:44 -0400 Message-ID: <32433.1433087744@sss.pgh.pa.us> X-Pg-Spam-Score: -1.9 (-) 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 Bruce Momjian writes: >> FYI, I realize that one additional thing that has discouraged code >> reorganization is the additional backpatch overhead. I think we now >> need to accept that our reorganization-adverse approach might have cost >> us some reliability, and that reorganization is going to add work to >> backpatching. > Actually, code reorganization in HEAD might cause backpatching to be > more buggy, reducing reliability --- obviously we need to have a > discussion about that. Commit 6b700301c36e380eb4972ab72c0e914cae60f9fd is a recent real example. Not that that should dissuade us from ever doing any reorganizations, but it's foolish to discount back-patching costs. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers