Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eIcay-0001Wz-BF for pgsql-performance@arkaria.postgresql.org; Sat, 25 Nov 2017 15:42:20 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eIcax-0002By-NW for pgsql-performance@arkaria.postgresql.org; Sat, 25 Nov 2017 15:42:19 +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 1eIcax-0002B9-HQ for pgsql-performance@lists.postgresql.org; Sat, 25 Nov 2017 15:42:19 +0000 Received: from sss.pgh.pa.us ([66.207.139.130]) by magus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.89) (envelope-from ) id 1eIcau-0000pw-Gq for pgsql-performance@postgresql.org; Sat, 25 Nov 2017 15:42:19 +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 vAPFgERF001666; Sat, 25 Nov 2017 10:42:14 -0500 From: Tom Lane To: Michael Paquier cc: Dmitry Shalashov , "pgsql-performance@postgresql.org" Subject: Re: Query became very slow after 9.6 -> 10 upgrade In-reply-to: References: <13426.1511363963@sss.pgh.pa.us> <9755.1511392027@sss.pgh.pa.us> <5549.1511456440@sss.pgh.pa.us> <28356.1511541575@sss.pgh.pa.us> Comments: In-reply-to Michael Paquier message dated "Sat, 25 Nov 2017 21:13:42 +0900" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <1664.1511624534.1@sss.pgh.pa.us> Date: Sat, 25 Nov 2017 10:42:14 -0500 Message-ID: <1665.1511624534@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk Michael Paquier writes: > On Sat, Nov 25, 2017 at 8:54 PM, Dmitry Shalashov wrote: >> Is it completely safe to use manually patched version in production? > Patching upstream PostgreSQL to fix a critical bug is something that > can of course be done. And to reach a state where you think something > is safe to use in production first be sure to test it thoroughly on a > stage instance. The author is also working on Postgres for 20 years, > so this gives some insurance. It's not like there's some magic dust that we sprinkle on the code at release time ;-). If there's a problem with that patch, it's much more likely that you'd discover it through field testing than that we would notice it during development (we missed the original problem after all). So you can do that field testing now, or after 10.2 comes out. The former seems preferable, if you are comfortable with building a patched copy at all. I don't know what your normal source of Postgres executables is, but all the common packaging technologies make it pretty easy to rebuild a package from source with patch(es) added. Modifying your vendor's SRPM (or equivalent concept if you're not on Red Hat) is a good skill to have. regards, tom lane