Re: [GENERAL] Upgrade method from 9.2 to 10 ?

gsql-general@postgresql.org Subject: Re: [GENERAL] Upgrade method from 9.2 to 10 ? On Fri, Jun 16, 2017 at 04:14:07PM -0400, Paul Jones wrote: > Would it be possible to upgrade from 9.2 to 10 by doing a pg_basebackup > to the new server, followed by pg_upgrade -k, then streaming replication > from the

Re: [GENERAL] Upgrade method from 9.2 to 10 ?

On Fri, Jun 16, 2017 at 04:14:07PM -0400, Paul Jones wrote: > Would it be possible to upgrade from 9.2 to 10 by doing a pg_basebackup > to the new server, followed by pg_upgrade -k, then streaming replication > from the 9.2 server to the 10 server until we're ready to cut over to 10? > > The idea

[GENERAL] Upgrade method from 9.2 to 10 ?

Would it be possible to upgrade from 9.2 to 10 by doing a pg_basebackup to the new server, followed by pg_upgrade -k, then streaming replication from the 9.2 server to the 10 server until we're ready to cut over to 10? The idea is to minimize downtime. PJ -- Sent via pgsql-general mailing

Re: [GENERAL] Upgrade from 9.5.4 to 9.6.1

On Tue, 15 Nov 2016, Adrian Klaver wrote: To add to my previous post. If you do decide to follow the pg_upgrade procedure in the README do a pg_dump of the 9.5 data just before you do pg_ugrade and store it away in a safe place. The first time through a new process does not always end well:)

Re: [GENERAL] Upgrade from 9.5.4 to 9.6.1

On Wed, 16 Nov 2016, Alban Hertroys wrote: pg_upgrade migrates your databases from your old (9.5) cluster to the new (9.6) one. Initdb doesn't do that. Alban, That's what I assumed to be the case. If your 9.6 database does indeed contain your databases, then something must have done the

Re: [GENERAL] Upgrade from 9.5.4 to 9.6.1

On 16 November 2016 at 16:33, Rich Shepard wrote: > On Tue, 15 Nov 2016, Rich Shepard wrote: > If 9.6.1 is currently running after running initdb, and I can access my > databases, what does pg_upgrade do that's necessary? pg_upgrade migrates your databases from your

Re: [GENERAL] Upgrade from 9.5.4 to 9.6.1

On Tue, 15 Nov 2016, Rich Shepard wrote: $ /usr/bin/pg_ctl --version pg_ctl (PostgreSQL) 9.6.1 ls -al /usr/bin/pg_ctl lrwxrwxrwx 1 root root 32 Nov 15 14:16 /usr/bin/pg_ctl -> ../lib/postgresql/9.6/bin/pg_ctl* To increase my understanding I want to resolve an apparent discrepancy in

Re: [GENERAL] Upgrade from 9.5.4 to 9.6.1

On Tue, 15 Nov 2016, Adrian Klaver wrote: So what do you get with /usr/bin/pg_ctl --version Interesting: $ /usr/bin/pg_ctl --version pg_ctl (PostgreSQL) 9.6.1 and given John's suggestion: ls -al /usr/bin/pg_ctl ls -al /usr/bin/pg_ctl lrwxrwxrwx 1 root root 32 Nov 15 14:16

Re: [GENERAL] Upgrade from 9.5.4 to 9.6.1

On 11/15/2016 05:18 PM, Rich Shepard wrote: On Tue, 15 Nov 2016, Adrian Klaver wrote: Rich is using Slackware and I am pretty sure it marches to a different drummer. Adrian, And a different band. Pat likes MariaDB which replaced MySQL so PostgreSQL is not part of the base distribution.

Re: [GENERAL] Upgrade from 9.5.4 to 9.6.1

On 11/15/2016 05:18 PM, Rich Shepard wrote: On Tue, 15 Nov 2016, Adrian Klaver wrote: Rich is using Slackware and I am pretty sure it marches to a different drummer. Adrian, And a different band. Pat likes MariaDB which replaced MySQL so PostgreSQL is not part of the base distribution.

Re: [GENERAL] Upgrade from 9.5.4 to 9.6.1

On 11/15/2016 05:06 PM, Rich Shepard wrote: On Tue, 15 Nov 2016, Adrian Klaver wrote: Assuming the bindirs are in your $PATH: aklaver@panda:~> whereis -f pg_ctl Adrian, In my case: $ whereis -f pg_ctl pg_ctl: /bin/pg_ctl /usr/bin/pg_ctl /usr/X11R6/bin/pg_ctl /usr/bin/X11/pg_ctl

Re: [GENERAL] Upgrade from 9.5.4 to 9.6.1

On Tue, 15 Nov 2016, Adrian Klaver wrote: Rich is using Slackware and I am pretty sure it marches to a different drummer. Adrian, And a different band. Pat likes MariaDB which replaced MySQL so PostgreSQL is not part of the base distribution. But, SlackBuilds.org provides a build script

Re: [GENERAL] Upgrade from 9.5.4 to 9.6.1

On 11/15/2016 05:01 PM, John R Pierce wrote: On 11/15/2016 4:55 PM, Adrian Klaver wrote: where do I look for the two bindirs? Assuming the bindirs are in your $PATH: aklaver@panda:~> whereis -f pg_ctl pg_ctl: /usr/local/pgsql/bin/pg_ctl /usr/local/pgsql94/bin/pg_ctl Even if only one is the

Re: [GENERAL] Upgrade from 9.5.4 to 9.6.1

On Tue, 15 Nov 2016, Adrian Klaver wrote: Assuming the bindirs are in your $PATH: aklaver@panda:~> whereis -f pg_ctl Adrian, In my case: $ whereis -f pg_ctl pg_ctl: /bin/pg_ctl /usr/bin/pg_ctl /usr/X11R6/bin/pg_ctl /usr/bin/X11/pg_ctl /usr/X11/bin/pg_ctl /usr/man/man1/pg_ctl.1

Re: [GENERAL] Upgrade from 9.5.4 to 9.6.1

On 11/15/2016 4:55 PM, Adrian Klaver wrote: where do I look for the two bindirs? Assuming the bindirs are in your $PATH: aklaver@panda:~> whereis -f pg_ctl pg_ctl: /usr/local/pgsql/bin/pg_ctl /usr/local/pgsql94/bin/pg_ctl Even if only one is the $PATH: aklaver@panda:~> whereis -f pg_ctl

Re: [GENERAL] Upgrade from 9.5.4 to 9.6.1

On Tue, 15 Nov 2016, John R Pierce wrote: 9.5 is considered a major version, 9.5.4 is a minor.this will change when 10 is released, from 10 on, major versions will be 10, 11, 12, ... John, So the upgrade from 9.5.4 to 9.6.1 is as I assumed: major. based on the data paths you gave,

Re: [GENERAL] Upgrade from 9.5.4 to 9.6.1

On 11/15/2016 02:37 PM, Rich Shepard wrote: All my previous version upgrades were performed by running pg_dumpall in the older version followed by running 'pgsql -f ...' to install the dumped .sql file, usually because the upgrade jumped several versions. Now I'd like to try the available

Re: [GENERAL] Upgrade from 9.5.4 to 9.6.1

On 11/15/2016 2:37 PM, Rich Shepard wrote: All my previous version upgrades were performed by running pg_dumpall in the older version followed by running 'pgsql -f ...' to install the dumped .sql file, usually because the upgrade jumped several versions. Now I'd like to try the available

[GENERAL] Upgrade from 9.5.4 to 9.6.1

All my previous version upgrades were performed by running pg_dumpall in the older version followed by running 'pgsql -f ...' to install the dumped .sql file, usually because the upgrade jumped several versions. Now I'd like to try the available postgres commands. The older version is

Re: [GENERAL] upgrade to repmgr3

hi 2016-08-04 16:19 GMT+03:00 Ian Barwick : > Hi > > On 08/04/2016 05:57 PM, Pekka Rinne wrote: > >> hi! >> >> I have been using postgres 9.4 and repmgr2.0 combination and been doing >> replication (hot standby). Now I'd like to start doing slot based >> replication and

Re: [GENERAL] upgrade to repmgr3

Hi, 2016-08-11 7:54 GMT-03:00 Pekka Rinne : >> >> Do you by chance have synchronous replication set? That ps output alone >> doesn't say much, but being stuck on COMMIT normally points to failure >> to sync the replication on a standby. >> > > Yeah, I learned that repmgr3

Re: [GENERAL] upgrade to repmgr3

hi 2016-08-09 15:39 GMT+03:00 Martín Marqués : > Hi, > > El 08/08/16 a las 05:57, Pekka Rinne escribió: > > > > Meanwhile I did some more testing with my environment using repmgr3 and > > noticed an issue with promoting standby node. Here is roughly what I did. > > > > 1.

Re: [GENERAL] upgrade to repmgr3

Hi, El 08/08/16 a las 05:57, Pekka Rinne escribió: > > Meanwhile I did some more testing with my environment using repmgr3 and > noticed an issue with promoting standby node. Here is roughly what I did. > > 1. Install repmgr3.1.2 RPM to all nodes as upgrade to previous 2.0.2. > 2. I took repmgr

Re: [GENERAL] upgrade to repmgr3

hello Thanks for your comments. They are very helpful. If you have any draft level documentation available of the upgrade procedure I would be very interested in seeing it and maybe trying it out as well. Meanwhile I did some more testing with my environment using repmgr3 and noticed an issue

Re: [GENERAL] upgrade to repmgr3

Hi On 08/04/2016 05:57 PM, Pekka Rinne wrote: hi! I have been using postgres 9.4 and repmgr2.0 combination and been doing replication (hot standby). Now I'd like to start doing slot based replication and have installed repmgr3 and exeuted the provided sql scripts and also added

[GENERAL] upgrade to repmgr3

hi! I have been using postgres 9.4 and repmgr2.0 combination and been doing replication (hot standby). Now I'd like to start doing slot based replication and have installed repmgr3 and exeuted the provided sql scripts and also added use_replication_slots=1 into repmgr.conf. The question is that

[GENERAL] Upgrade from 9.4 -> 9.5, FreeBSD 10.2-STABLE, fails on initdb

$ initdb -D data-default The files belonging to this database system will be owned by user "pgsql". This user must also own the server process. The database cluster will be initialized with locale "C". The default database encoding has accordingly been set to "SQL_ASCII". The default text search

Re: [GENERAL] Upgrade from 9.4 -> 9.5, FreeBSD 10.2-STABLE, fails on initdb

I wrote: > Karl Denninger writes: >> $ initdb -D data-default >> ... >> creating template1 database in data-default/base/1 ... FATAL: could not >> create semaphores: Invalid argument >> DETAIL: Failed system call was semget(2, 17, 03600). > Hmm. On my Linux box, "man

Re: [GENERAL] Upgrade from 9.4 -> 9.5, FreeBSD 10.2-STABLE, fails on initdb

On 2/4/2016 12:47, Tom Lane wrote: > I wrote: >> Karl Denninger writes: >>> $ initdb -D data-default >>> ... >>> creating template1 database in data-default/base/1 ... FATAL: could not >>> create semaphores: Invalid argument >>> DETAIL: Failed system call was semget(2, 17,

Re: [GENERAL] Upgrade from 9.4 -> 9.5, FreeBSD 10.2-STABLE, fails on initdb

On 02/04/2016 10:02 AM, Karl Denninger wrote: $ initdb -D data-default The files belonging to this database system will be owned by user "pgsql". This user must also own the server process. The database cluster will be initialized with locale "C". The default database encoding has accordingly

Re: [GENERAL] Upgrade from 9.4 -> 9.5, FreeBSD 10.2-STABLE, fails on initdb

Karl Denninger writes: > $ initdb -D data-default > ... > creating template1 database in data-default/base/1 ... FATAL: could not > create semaphores: Invalid argument > DETAIL: Failed system call was semget(2, 17, 03600). Hmm. On my Linux box, "man semget" says EINVAL

Re: [GENERAL] Upgrade from 9.4 -> 9.5, FreeBSD 10.2-STABLE, fails on initdb

On 02/04/2016 10:02 AM, Karl Denninger wrote: $ initdb -D data-default The files belonging to this database system will be owned by user "pgsql". This user must also own the server process. The database cluster will be initialized with locale "C". The default database encoding has accordingly

Re: [GENERAL] Upgrade from 9.4 -> 9.5, FreeBSD 10.2-STABLE, fails on initdb

On 2/4/2016 12:28, Tom Lane wrote: > Karl Denninger writes: >> $ initdb -D data-default >> ... >> creating template1 database in data-default/base/1 ... FATAL: could not >> create semaphores: Invalid argument >> DETAIL: Failed system call was semget(2, 17, 03600). > Hmm.

Re: [GENERAL] Upgrade from 9.3 to 9.4 issue

On 31/10/15 13:32, Tom Lane wrote: Stephen Davies writes: I have just upgraded from Fedora 21 to 22. This included an upgrade of PostgreSQL from 9.3 to 9.4 which causes postmaster to fail because the existing databases are still at 9.3. As suggested, I then ran

[GENERAL] Upgrade from 9.3 to 9.4 issue

I have just upgraded from Fedora 21 to 22. This included an upgrade of PostgreSQL from 9.3 to 9.4 which causes postmaster to fail because the existing databases are still at 9.3. As suggested, I then ran postgresql-setup --upgrade but this failed with: Performing Consistency Checks

Re: [GENERAL] Upgrade from 9.3 to 9.4 issue

Stephen Davies writes: > I have just upgraded from Fedora 21 to 22. > This included an upgrade of PostgreSQL from 9.3 to 9.4 which causes > postmaster > to fail because the existing databases are still at 9.3. > As suggested, I then ran postgresql-setup --upgrade but this

[GENERAL] Upgrade from postgresql-9.5alpha1 to postgresql-9.5alpha2 (Debian packages)

It looks like the catalog version has changed between 9.5alpha1 and 9.5alpha2: FATAL: database files are incompatible with server DETAIL: The database cluster was initialized with CATALOG_VERSION_NO 201506282, but the server was compiled with CATALOG_VERSION_NO 201507281. HINT:

Re: [GENERAL] Upgrade from postgresql-9.5alpha1 to postgresql-9.5alpha2 (Debian packages)

On Tue, Aug 18, 2015 at 6:06 PM, Peter J. Holzer hjp-pg...@hjp.at wrote: It looks like the catalog version has changed between 9.5alpha1 and 9.5alpha2: FATAL: database files are incompatible with server DETAIL: The database cluster was initialized with CATALOG_VERSION_NO 201506282,

Re: [GENERAL] Upgrade from postgresql-9.5alpha1 to postgresql-9.5alpha2 (Debian packages)

On 2015-08-18 20:40:10 +0900, Masahiko Sawada wrote: On Tue, Aug 18, 2015 at 6:06 PM, Peter J. Holzer hjp-pg...@hjp.at wrote: It looks like the catalog version has changed between 9.5alpha1 and 9.5alpha2: [...] So, what's the best way to do the upgrade? * Copy the bindir before the

[GENERAL] Upgrade postgres cluster on FreeBSD using pg_upgrade

Hi I need to upgrade a PG cluster from 9.1 to 9.4 running on dedicated FreeBSD 9.2 server. Earlier I followed the simple pg_dump / pg_restore, but now that the cluster has grown to around 700 GB (1 TB total HD size), I am now inclined towards using pg_upgrade. pg_upgrade requires both binary to

Re: [GENERAL] Upgrade postgres cluster on FreeBSD using pg_upgrade

It's actually simpler than you think. Here are the steps that I follow: 1. Install 9.4 in another directory, if you compile it from the ports make suere you add the PREFIX flag. For example: cd /usr/ports/databases/postgresql94-server/ make install clean PREFIX=/opt, this will install 9.4 on the

Re: [GENERAL] Upgrade postgres cluster on FreeBSD using pg_upgrade

On Mon, Jul 20, 2015 at 1:57 AM, Joseph Kregloh jkreg...@sproutloud.com wrote: It's actually simpler than you think. Here are the steps that I follow: 1. Install 9.4 in another directory, if you compile it from the ports make suere you add the PREFIX flag. For example: cd

[GENERAL] Upgrade to 9.3 - performance issue ?

Hello, We were planing to upgrade from 9.0 to to 9.3. While investigating on the performance side, we stumbled upon a link which says there may be performance degradation on 9.3:

[GENERAL] Upgrade to 9.3

Hello, We are planning to upgrade Postgres from 9.0 to 9.3. Was wondering if there are any serious changes that I have to look out for (syntax/datatypes changes) so that my code does not break. Thanks in advance. - Karthik -- Sent via pgsql-general mailing list

Re: [GENERAL] Upgrade to 9.3

On Monday, July 21, 2014 09:05:18 PM Karthik Iyer wrote: Hello, We are planning to upgrade Postgres from 9.0 to 9.3. Was wondering if there are any serious changes that I have to look out for (syntax/datatypes changes) so that my code does not break.

Re: [GENERAL] Upgrade to 9.3

unsubscribe On Mon, Jul 21, 2014 at 1:22 PM, Alan Hodgson ahodg...@simkin.ca wrote: On Monday, July 21, 2014 09:05:18 PM Karthik Iyer wrote: Hello, We are planning to upgrade Postgres from 9.0 to 9.3. Was wondering if there are any serious changes that I have to look out for

[GENERAL] Upgrade: 9.0.5-9.4

Postgresql-9.0.5 is installed in /usr/local/pgsql/ and -9.4's data/ subdirectory is installed in /var/lib/pgsql/9.4/ with the executable in /usr/bin/. Running pg_upgrade fails at the end because of a locale difference: lc_ctype cluster values do not match: old C, new en_US.UTF-8 Failure,

Re: [GENERAL] Upgrade: 9.0.5-9.4

On Fri, Mar 21, 2014 at 9:34 AM, Rich Shepard rshep...@appl-ecosys.com wrote: Postgresql-9.0.5 is installed in /usr/local/pgsql/ and -9.4's data/ subdirectory is installed in /var/lib/pgsql/9.4/ with the executable in /usr/bin/. Running pg_upgrade fails at the end because of a locale

Re: [GENERAL] Upgrade: 9.0.5-9.4

On 03/21/2014 09:34 AM, Rich Shepard wrote: Postgresql-9.0.5 is installed in /usr/local/pgsql/ and -9.4's data/ subdirectory is installed in /var/lib/pgsql/9.4/ with the executable in /usr/bin/. Running pg_upgrade fails at the end because of a locale difference: lc_ctype cluster values

Re: [GENERAL] Upgrade: 9.0.5-9.4

On Fri, 21 Mar 2014, Sergey Konoplev wrote: Drop your newly created 9.4 cluster dir and re-init it with C locale like this: Sergey, How do I drop the cluster? I've not had need to do this before. initdb --locale=C -D ... Do I want the former locale or the current one; does it make

Re: [GENERAL] Upgrade: 9.0.5-9.4

On Fri, 21 Mar 2014, Joshua D. Drake wrote: If you want to use pg_upgrade, then you are going to have to dump your old database, clean it to UTF-8 (with say iconv), then reimport it. At that point you might as well just pull it into 9.3. Joshua, I did a pg_dumpall before starting this

Re: [GENERAL] Upgrade: 9.0.5-9.4

On Fri, 21 Mar 2014, Rich Shepard wrote: I did a pg_dumpall before starting this process. If I can use pg_restore on the running 9.4 will that convert locales and get the job done? Let me be more specific. Can I get databases working again by doing these steps? 1.) Start the new -9.4

Re: [GENERAL] Upgrade: 9.0.5-9.4

On Fri, 21 Mar 2014, Rich Shepard wrote: 1.) Start the new -9.4 version running. It's now running. 2.) Run pg_restore on each database that's in the .sql file created by pg_dumpall. Will this work? psql -e -d template1 -f

Re: [GENERAL] Upgrade: 9.0.5-9.3.4 [RESOLVED]

On Fri, 21 Mar 2014, Rich Shepard wrote: psql -e -d template1 -f /home/rshepard/data/database-backups/pg-9.0.5-2014-03-17.sql Yep. Now all databases are running on 9.3.4. Thanks, all! Rich -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your

Re: [GENERAL] Upgrade: 9.0.5-9.3.3

On Mon, 17 Mar 2014, Rich Shepard wrote: Now, -9.0.5 is installed in /usr/local/pgsql/ and -9.3.3 is installed in /opt/pgsql-9.3.3. I want to use pg_upgrade and have read the Web page with the instructions. I am having problems initializing the new version in /opt/pgsql-9.3.3. I kill the

Re: [GENERAL] Upgrade: 9.0.5-9.3.3

Rich Shepard rshep...@appl-ecosys.com writes: On Mon, 17 Mar 2014, Rich Shepard wrote: Now, -9.0.5 is installed in /usr/local/pgsql/ and -9.3.3 is installed in /opt/pgsql-9.3.3. I want to use pg_upgrade and have read the Web page with the instructions. I am having problems initializing

Re: [GENERAL] Upgrade: 9.0.5-9.3.3

On Tue, 18 Mar 2014, Tom Lane wrote: Your PATH seems to be finding initdb in /bin (or is that /usr/bin), not the one you want under /opt/pgsql-9.3.3. Tom, Thanks for catching what I did not see. There was an initdb from 2011 in /bin/ and the new one in /usr/bin/ is a softlink to

[GENERAL] Upgrade: 9.0.5-9.3.3

Now, -9.0.5 is installed in /usr/local/pgsql/ and -9.3.3 is installed in /opt/pgsql-9.3.3. I want to use pg_upgrade and have read the Web page with the instructions. Instruction #4 tells me to install pg_upgrade and pg_upgrade_support. I have the 9.0.5 version of pg_upgrade in

Re: [GENERAL] Upgrade: 9.0.5-9.3.3

Rich Shepard rshep...@appl-ecosys.com writes: Now, -9.0.5 is installed in /usr/local/pgsql/ and -9.3.3 is installed in /opt/pgsql-9.3.3. I want to use pg_upgrade and have read the Web page with the instructions. I'm guessing from those path names that you are using self-compiled

Re: [GENERAL] Upgrade: 9.0.5-9.3.3

On Mon, 17 Mar 2014, Tom Lane wrote: I'm guessing from those path names that you are using self-compiled executables, not somebody's packaging? If the latter, whose? I'm confused as to how you got pg_upgrade installed without knowing where it came from. Tom, Both were buit with scripts

Re: [GENERAL] Upgrade from 9.1 to 9.10

Thanks much. It is of great help. -- View this message in context: http://postgresql.1045698.n5.nabble.com/Upgrade-from-9-1-to-9-10-tp5775290p5775534.html Sent from the PostgreSQL - general mailing list archive at Nabble.com. -- Sent via pgsql-general mailing list

[GENERAL] Upgrade from 9.1 to 9.10

Hi All, I am relatively new to postgres and need to upgrade postgres 9.1.1 to 9.1.10. As I understood from the documentation that Upgrading to a minor release does not require a dump and restore; merely stop the database server, install the updated binaries, and restart the server Is there any

Re: [GENERAL] Upgrade from 9.1 to 9.10

On 10/21/2013 10:57 AM, ramistuni wrote: Hi All, I am relatively new to postgres and need to upgrade postgres 9.1.1 to 9.1.10. As I understood from the documentation that Upgrading to a minor release does not require a dump and restore; merely stop the database server, install the updated

Re: [GENERAL] Upgrade from 9.1 to 9.10

ramistuni wrote We are currently running PostgreSQL 9.1.1 on x86_64-unknown-linux-gnu, compiled by gcc (GCC) 4.1.2 20080704 (Red Hat 4.1.2-51), 64-bit This is packaging (thus Linux Distro) concern and not that of PostgreSQL proper. As I use Ubuntu and you appear to be using a Red Hat variant

Re: [GENERAL] Upgrade from 9.1 to 9.10

Thanks so much David and John for your quick responses. These databases were recently transitioned to me from a team which are not part of our organization any more. Please bare with my knowledge, but is there any way to find if the past installations were done using YUM? We have been given

Re: [GENERAL] Upgrade from 9.1 to 9.10

On 10/21/2013 12:00 PM, ramistuni wrote: Please bare with my knowledge, but is there any way to find if the past installations were done using YUM? This is all standard redhat installation/administration stuff... # rpm -qf /usr/pgsql-9.2/bin/postgres

Re: [GENERAL] Upgrade from 9.1 to 9.10

On 10/21/2013 12:15 PM, John R Pierce wrote: # rpm -qf /etc/yum.repos.d/pgdg-9* pgdg-centos90-9.0-5.noarch pgdg-centos92-9.2-6.noarch you should see the 91 version. oh, to clarify something.the version of that pgdg-.noarch repository file is NOT directly related to the

Re: [GENERAL] upgrade from 9.2.x to 9.3 causes significant performance degradation

Lonni J Friedman netll...@gmail.com wrote: top shows over 90% of the load is in sys space.  vmstat output seems to suggest that its CPU bound (or bouncing back forth): Can you run `perf top` during an episode and see what kernel functions are using all that CPU? This looks similar to cases

Re: [GENERAL] upgrade from 9.2.x to 9.3 causes significant performance degradation

On Wed, Sep 18, 2013 at 2:02 AM, Kevin Grittner kgri...@ymail.com wrote: Lonni J Friedman netll...@gmail.com wrote: top shows over 90% of the load is in sys space. vmstat output seems to suggest that its CPU bound (or bouncing back forth): Can you run `perf top` during an episode and see

Re: [GENERAL] upgrade from 9.2.x to 9.3 causes significant performance degradation

On Wed, Sep 18, 2013 at 2:02 AM, Kevin Grittner kgri...@ymail.com wrote: Lonni J Friedman netll...@gmail.com wrote: top shows over 90% of the load is in sys space. vmstat output seems to suggest that its CPU bound (or bouncing back forth): Can you run `perf top` during an episode and see

Re: [GENERAL] upgrade from 9.2.x to 9.3 causes significant performance degradation

On Wed, Sep 18, 2013 at 10:30 AM, Lonni J Friedman netll...@gmail.comwrote: This looks similar to cases I've seen of THP defrag going wild. Did the OS version or configuration change? Did the PostgreSQL memory settings (like shared_buffers) change? I think you're onto something here

[GENERAL] upgrade from 9.2.x to 9.3 causes significant performance degradation

Greetings, I'm running a PostgreSQL 9.3.0 cluster (1 master with two streaming replication hot standby slaves) on RHEL6-x86_64. Yesterday I upgraded from 9.2.4 to 9.3.0, and since the upgrade I'm seeing a significant performance degradation. PostgreSQL simply feels slower. Nothing other than

Re: [GENERAL] upgrade from 9.2.x to 9.3 causes significant performance degradation

On Tue, 17 Sep 2013 09:19:29 -0700 Lonni J Friedman netll...@gmail.com wrote: Greetings, I'm running a PostgreSQL 9.3.0 cluster (1 master with two streaming replication hot standby slaves) on RHEL6-x86_64. Yesterday I upgraded from 9.2.4 to 9.3.0, and since the upgrade I'm seeing a

Re: [GENERAL] upgrade from 9.2.x to 9.3 causes significant performance degradation

On Tue, Sep 17, 2013 at 9:54 AM, Eduardo Morras emorr...@yahoo.es wrote: On Tue, 17 Sep 2013 09:19:29 -0700 Lonni J Friedman netll...@gmail.com wrote: Greetings, I'm running a PostgreSQL 9.3.0 cluster (1 master with two streaming replication hot standby slaves) on RHEL6-x86_64. Yesterday I

Re: [GENERAL] upgrade from 9.2.x to 9.3 causes significant performance degradation

On Tue, Sep 17, 2013 at 11:22 AM, Lonni J Friedman netll...@gmail.comwrote: c) What does logs say? The postgres server logs look perfectly normal, minus a non-trivial slower run time for most queries. There's nothing unusual in any of the OS level logs (/var/log/messages, etc) or dmesg.

Re: [GENERAL] upgrade from 9.2.x to 9.3 causes significant performance degradation

Thanks for your reply. Comments/answers inline below On Tue, Sep 17, 2013 at 11:28 AM, Jeff Janes jeff.ja...@gmail.com wrote: On Tue, Sep 17, 2013 at 11:22 AM, Lonni J Friedman netll...@gmail.com wrote: c) What does logs say? The postgres server logs look perfectly normal, minus a

Re: [GENERAL] upgrade from 9.2.x to 9.3 causes significant performance degradation

Hi, On 2013-09-17 09:19:29 -0700, Lonni J Friedman wrote: I'm running a PostgreSQL 9.3.0 cluster (1 master with two streaming replication hot standby slaves) on RHEL6-x86_64. Yesterday I upgraded from 9.2.4 to 9.3.0, and since the upgrade I'm seeing a significant performance degradation.

Re: [GENERAL] upgrade from 9.2.x to 9.3 causes significant performance degradation

On Tue, Sep 17, 2013 at 3:47 PM, Andres Freund and...@2ndquadrant.com wrote: Hi, On 2013-09-17 09:19:29 -0700, Lonni J Friedman wrote: I'm running a PostgreSQL 9.3.0 cluster (1 master with two streaming replication hot standby slaves) on RHEL6-x86_64. Yesterday I upgraded from 9.2.4 to

Re: [GENERAL] Upgrade from 9.1 to 9.2 fails due to unlogged table?

I repeated the entire process, and I have a few clarifications. When I said the db seemed fine after the restore, I was wrong. I could do a \d on an unlogged table, but when I selected count(*) from any, that resulted in an error like could not open file base/16388/15963587: No such file or

[GENERAL] Upgrade from 9.1 to 9.2 fails due to unlogged table?

I have a 9.1.3 instance (Redhat 5) with some unlogged tables. I did the following steps: 1. pg_basebackup to create a base.tar 2. Used the base.tar plus the WALs required by the backup to restore the db to another 9.1.3 server. This went fine, except at the end of the recovery I got this error

[GENERAL] Upgrade from 8.4.13 to 9.2.0.1 successful but it still displays 8.4.13 if SELECT version();

Hi, I have upgraded postgresql 8.4.13 to 9.2.0.1 O/S Ubuntu, restarted postgresql, it displayed my postgresql is 9.2 but when I log into postgresql, show version, it is still 8.4.13, see a) and b) below, a) * Restarting PostgreSQL 9.2 database server ...done. b) psql (8.4.13) Type help

Re: [GENERAL] Upgrade from 8.4.13 to 9.2.0.1 successful but it still displays 8.4.13 if SELECT version();

On 2012-09-23 14:47, a...@hsk.hk wrote: Hi, I have upgraded postgresql 8.4.13 to 9.2.0.1 O/S Ubuntu, restarted postgresql, it displayed my postgresql is 9.2 but when I log into postgresql, show version, it is still 8.4.13, see a) and b) below, a) * Restarting PostgreSQL 9.2 database server

Re: [GENERAL] Upgrade from 8.4.13 to 9.2.0.1 successful but it still displays 8.4.13 if SELECT version();

On 09/23/2012 04:47 AM, a...@hsk.hk wrote: Hi, I have upgraded postgresql 8.4.13 to 9.2.0.1 O/S Ubuntu, restarted postgresql, it displayed my postgresql is 9.2 but when I log into postgresql, show version, it is still 8.4.13, see a) and b) below, a) * Restarting PostgreSQL 9.2 database

Re: [GENERAL] Upgrade from 8.4.13 to 9.2.0.1 successful but it still displays 8.4.13 if SELECT version();

On 23/09/12 11:48, Adrian Klaver wrote: On 09/23/2012 04:47 AM, a...@hsk.hk wrote: Hi, I have upgraded postgresql 8.4.13 to 9.2.0.1 O/S Ubuntu, restarted postgresql, it displayed my postgresql is 9.2 but when I log into postgresql, show version, it is still 8.4.13, see a) and b) below, My

Re: [GENERAL] Upgrade from 8.4.13 to 9.2.0.1 successful but it still displays 8.4.13 if SELECT version();

On 23/09/2012 19:31, Martin Collins wrote: On 23/09/12 11:48, Adrian Klaver wrote: On 09/23/2012 04:47 AM, a...@hsk.hk wrote: Hi, I have upgraded postgresql 8.4.13 to 9.2.0.1 O/S Ubuntu, restarted postgresql, it displayed my postgresql is 9.2 but when I log into postgresql, show version,

Re: [GENERAL] Upgrade from 8.4.13 to 9.2.0.1 successful but it still displays 8.4.13 if SELECT version();

Hi thanks, I ran ps and found there were TWO postgresql postgres 1124 0.0 0.1 45116 5480 ?SSep23 0:01 /usr/lib/postgresql/8.4/bin/postgres -D /var/lib/postgresql/8.4/main -c config_file=/etc/postgresql/8.4/main/postgresql.conf postgres 1133 0.0 0.0 45116 1984 ?

Re: [GENERAL] upgrade causes psql to not work

I looked on the http://jdbc.postgresql.org/ and could not find any docs on the jdbc string to use my old one with localhost and 127.0.0.1 do not work any more. here is the conf # local is for Unix domain socket connections only local all all trust # IPv4 local connections: host all all

Re: [GENERAL] upgrade causes psql to not work

On 07/26/2012 10:59 AM, BJ Freeman wrote: I looked on the http://jdbc.postgresql.org/ and could not find any docs on the jdbc string to use my old one with localhost and 127.0.0.1 do not work any more. here is the conf # local is for Unix domain socket connections only local all all trust # IPv4

[GENERAL] upgrade causes psql to not work

did a centos 5.6 server upgrade to PostgreSQL version 8.4.12. console: [root@main jdbc]# psql -h localhost -U gameserver passwordfromentityengine.xml psql: could not connect to server: Connection refused Is the server running on host localhost and accepting TCP/IP connections

Re: [GENERAL] upgrade causes psql to not work

On Wed, Jul 25, 2012 at 9:57 AM, BJ Freeman bjf...@free-man.net wrote: did a centos 5.6 server upgrade to PostgreSQL version 8.4.12. console: [root@main jdbc]# psql -h localhost -U gameserver passwordfromentityengine.xml psql: could not connect to server: Connection refused Is the

Re: [GENERAL] upgrade causes psql to not work

I apologize, psql is running if I do [root@main jdbc]# psql -U gameserver passwordfromentityengine.xml with out defining the host, it works. I believe it is using Unix pipes instead of TCP I also can manage the psql server through webmin. Merlin Moncure sent the following on 7/25/2012 8:16

Re: [GENERAL] upgrade causes psql to not work

On Wed, Jul 25, 2012 at 10:48 AM, BJ Freeman bjf...@free-man.net wrote: I apologize, psql is running if I do [root@main jdbc]# psql -U gameserver passwordfromentityengine.xml with out defining the host, it works. I believe it is using Unix pipes instead of TCP I also can manage the psql

Re: [GENERAL] upgrade causes psql to not work

On Wed, Jul 25, 2012 at 11:42 AM, Merlin Moncure mmonc...@gmail.com wrote: On Wed, Jul 25, 2012 at 10:48 AM, BJ Freeman bjf...@free-man.net wrote: I apologize, psql is running if I do [root@main jdbc]# psql -U gameserver passwordfromentityengine.xml with out defining the host, it works.

Re: [GENERAL] Upgrade questions

On 2012-03-12, Carson Gross carsongr...@gmail.com wrote: We've got a postgres database with *a lot* of data in one table. On the order of 100 million rows at this point. Postgres is, of course, handling it with aplomb. ALTER TABLE my_table ALTER COLUMN id TYPE bigint; However, given

Re: [GENERAL] Upgrade questions

On 03/13/12 8:41 PM, Carson Gross wrote: Does anyone have a reasonable guess as to the inserts per second postgres is capable of these days on middle-of-the-road hardware? Any order of magnitude would be fine: 10, 100, 1000, 10,000. my dedicated database server in my lab, which is a 2U dual

Re: [GENERAL] Upgrade questions

I felt pretty good about my server until I read this. On Wed, 2012-03-14 at 00:24 -0700, John R Pierce wrote: On 03/13/12 8:41 PM, Carson Gross wrote: Does anyone have a reasonable guess as to the inserts per second postgres is capable of these days on middle-of-the-road hardware? Any

Re: [GENERAL] Upgrade questions

Heh. OK, so I'll plan on about 100 writes per second... *gulp* Thanks a bunch for the info guys. Cheers, Carson On Wed, Mar 14, 2012 at 7:54 AM, Bret Stern bret_st...@machinemanagement.com wrote: I felt pretty good about my server until I read this. On Wed, 2012-03-14 at 00:24 -0700, John

Re: [GENERAL] Upgrade questions

On 03/14/12 12:24 AM, John R Pierce wrote: thats my definition of a middle of the road database server. I have no idea what yours is. let me add... this server was under $7000 plus the disk drives (it actually has 25 drives, 20 are in the raid10 used for the database testing).we

Re: [GENERAL] Upgrade questions

On 03/14/2012 12:04 PM, John R Pierce wrote: On 03/14/12 12:24 AM, John R Pierce wrote: thats my definition of a middle of the road database server. I have no idea what yours is. let me add... this server was under $7000 plus the disk drives (it actually has 25 drives... My car was

Re: [GENERAL] Upgrade questions

On 03/14/12 12:16 PM, Steve Crawford wrote: I was just looking at some modest-sized 15k SAS drives that priced out in the $400-550 range. 25 of them would add a minimum of $10,000 to the price tag. Still under 6-figures, though. those disks aren't any cheaper when they are behind a EMC or

  1   2   3   4   >