Thread: Minor revision downgrade (9.2.11 -> 9.2.10)

Minor revision downgrade (9.2.11 -> 9.2.10)

From
Fabio Ugo Venchiarutti
Date:
Hello


I work as the DBA in a startup, and we're running a mid-range
linux+PostgreSQL stack (1.1 TB database, ~75% of which is multimedia data).

This is our version() string.

PostgreSQL 9.2.11 on x86_64-unknown-linux-gnu, compiled by gcc (GCC)
4.4.7 20120313 (Red Hat 4.4.7-11), 64-bit


A couple days ago we made a beginners mistake and upgraded our minor
from 9.2.10 to 9.2.11 on the same night as an hardware swap over due to
HW issues (according to our supplier, the chassis is like by like the
same specs as the replaced one, and discs have been moved over).


Severe performance issues hit us since.
We've done all the profiling, our I/O is minimal as usual, cache hit
rates are just as high as usual, all query plans are the same, the
application hasn't changed at all and yet everything is unbearably slow.


We're fairly confident that it's an issue with the hardware but we have
political reasons to downgrade PG to 9.2.10 to show the hosting supplier
that it's their fault.


The release notes for 9.2.11 mention no data structure changes (in line
with the usual PG versioning policy). Is it just as safe to downgrade
too? We tested it on a couple non-critical boxes to no ill effect
whatsoever, but we'd like a second opinion before we do it on the live
installation too.


TIA and best regards



Fabio


Re: Minor revision downgrade (9.2.11 -> 9.2.10)

From
Bruce Momjian
Date:
On Tue, Jun  2, 2015 at 04:40:15PM +1200, Fabio Ugo Venchiarutti wrote:
> We're fairly confident that it's an issue with the hardware but we
> have political reasons to downgrade PG to 9.2.10 to show the hosting
> supplier that it's their fault.
>
>
> The release notes for 9.2.11 mention no data structure changes (in
> line with the usual PG versioning policy). Is it just as safe to
> downgrade too? We tested it on a couple non-critical boxes to no ill
> effect whatsoever, but we'd like a second opinion before we do it on
> the live installation too.

I have rarely seen this question asked.  I think minor-release
downgrading is fine in this case.

--
  Bruce Momjian  <bruce@momjian.us>        http://momjian.us
  EnterpriseDB                             http://enterprisedb.com

  + Everyone has their own god. +


Re: Minor revision downgrade (9.2.11 -> 9.2.10)

From
Melvin Davidson
Date:
I hate to ask the obvious, but have you made sure you copied over the postgresql.conf and pg_hba.conf to make it identical?

On Tue, Jun 2, 2015 at 7:39 AM, Bruce Momjian <bruce@momjian.us> wrote:
On Tue, Jun  2, 2015 at 04:40:15PM +1200, Fabio Ugo Venchiarutti wrote:
> We're fairly confident that it's an issue with the hardware but we
> have political reasons to downgrade PG to 9.2.10 to show the hosting
> supplier that it's their fault.
>
>
> The release notes for 9.2.11 mention no data structure changes (in
> line with the usual PG versioning policy). Is it just as safe to
> downgrade too? We tested it on a couple non-critical boxes to no ill
> effect whatsoever, but we'd like a second opinion before we do it on
> the live installation too.

I have rarely seen this question asked.  I think minor-release
downgrading is fine in this case.

--
  Bruce Momjian  <bruce@momjian.us>        http://momjian.us
  EnterpriseDB                             http://enterprisedb.com

  + Everyone has their own god. +


--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general



--
Melvin Davidson
I reserve the right to fantasize.  Whether or not you
wish to share my fantasy is entirely up to you.

Re: Minor revision downgrade (9.2.11 -> 9.2.10)

From
Fabio Ugo Venchiarutti
Date:
Hi


Perfectly legitimate question.

The migration was just physical storage relocation, so the entirety of
the root file system, configuration and data was simply moved between
physical boxes.


As it turns out, the fault was at both ends in different stages: during
the first wave of outages they had bad CPU throttling settings on the
machine hardware.


That didn't improve performance by much tho: the real culprit was some
months-old package manager mishap reverting transparent huge pages to
"always" in the kernel (it was set and protected from change after a
previous troubleshooting hell).


For some reason it didn't bite us until we moved to this new machine.
And yes, there has been a reboot after the reversal. Perhaps we just got
lucky with memory allocation patterns up to that point


Thank you everyone.


Best regards


Fabio




On 03/06/15 01:20, Melvin Davidson wrote:
> I hate to ask the obvious, but have you made sure you copied over the
> postgresql.conf and pg_hba.conf to make it identical?
>
> On Tue, Jun 2, 2015 at 7:39 AM, Bruce Momjian <bruce@momjian.us
> <mailto:bruce@momjian.us>> wrote:
>
>     On Tue, Jun  2, 2015 at 04:40:15PM +1200, Fabio Ugo Venchiarutti wrote:
>     > We're fairly confident that it's an issue with the hardware but we
>     > have political reasons to downgrade PG to 9.2.10 to show the hosting
>     > supplier that it's their fault.
>     >
>     >
>     > The release notes for 9.2.11 mention no data structure changes (in
>     > line with the usual PG versioning policy). Is it just as safe to
>     > downgrade too? We tested it on a couple non-critical boxes to no ill
>     > effect whatsoever, but we'd like a second opinion before we do it on
>     > the live installation too.
>
>     I have rarely seen this question asked.  I think minor-release
>     downgrading is fine in this case.
>
>     --
>        Bruce Momjian  <bruce@momjian.us <mailto:bruce@momjian.us>>
>     http://momjian.us
>        EnterpriseDB http://enterprisedb.com
>
>        + Everyone has their own god. +
>
>
>     --
>     Sent via pgsql-general mailing list (pgsql-general@postgresql.org
>     <mailto:pgsql-general@postgresql.org>)
>     To make changes to your subscription:
>     http://www.postgresql.org/mailpref/pgsql-general
>
>
>
>
> --
> *Melvin Davidson*
> I reserve the right to fantasize.  Whether or not you
> wish to share my fantasy is entirely up to you.