Re: Query became very slow after 9.6 -> 10 upgrade - Mailing list pgsql-performance

From Dmitry Shalashov
Subject Re: Query became very slow after 9.6 -> 10 upgrade
Date
Msg-id CAKPeCUG8BBjQ0Pdqjft4VkU5ij+XnMufEu7k=QnyP9_A_cKOXA@mail.gmail.com
Whole thread Raw
In response to Re: Query became very slow after 9.6 -> 10 upgrade  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-performance
Ok, understood :-) Dmitry Shalashov, relap.io & surfingbird.ru 2017-11-25 18:42 GMT+03:00 Tom Lane : > 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 >

pgsql-performance by date:

Previous
From: Tom Lane
Date:
Subject: Re: Query became very slow after 9.6 -> 10 upgrade
Next
From: Jean Baro
Date:
Subject: Half billion records in one table? RDS