You can use Slony to replicate between different major versions.
Sent via the Samsung Galaxy S® 6, an AT&T 4G LTE smartphone
Original message From: Bruce Momjian Date:
6/16/17 16:18 (GMT-05:00) To: Paul Jones Cc:
pgsql-general@postgresql.org Subject: Re: [GENERAL] Upg
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
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 list
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:)
A
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 p
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 old (9.5) cluster to the
ne
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
version
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 /usr/bin/pg_ct
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. But
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. But
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 /usr/X11/
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 tha
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 $
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
/usr/man/ma
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
pg_c
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, I'm
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 postg
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 pos
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 install
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 have installed repmgr3 and
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 actually writes to DB dur
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. Install repmgr3.1.2 RPM
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
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 wit
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 use_replication_
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 w
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, 03600).
>> Hmm. On
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 semget" says EINVAL means
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. On my Linux box, "man
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 means
EINVAL nse
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 be
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 be
$ 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 c
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 postgresql-setup --upgrade but th
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 failed with:
> lc_colla
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
On 2015-08-18 20:40:10 +0900, Masahiko Sawada wrote:
> On Tue, Aug 18, 2015 at 6:06 PM, Peter J. Holzer 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 upgrade (o
On Tue, Aug 18, 2015 at 6:06 PM, Peter J. Holzer 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,
> but
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: It
On Mon, Jul 20, 2015 at 1:57 AM, Joseph Kregloh
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
> /usr/ports/databases/postgresql94-serv
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 th
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 b
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:
http://postgresql.1045698.n5.nabble.com/upgrade-from-9-2-x-to-9-3-causes-significant-performance-degrada
unsubscribe
On Mon, Jul 21, 2014 at 1:22 PM, Alan Hodgson 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
> > (syntax/dat
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.
>
http://www.postgresql.org/do
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 (pgsql-general@postgresq
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 s
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
/home/rshepard/data/database-backups/pg-9.0.5-2014-03.17.sq
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 vers
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 proc
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 any
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
On Fri, Mar 21, 2014 at 9: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
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
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
../lib/post
Rich Shepard 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 the new version in
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 po
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 fr
Rich Shepard 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
executables, not somebody's packa
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 /opt/postgresql
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 (pgsql-general@postgresql.o
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 s
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
postgresql92-server-9.2.5-1PGDG.rhel6
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 VMs
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 varia
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 bina
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
st
On Wed, Sep 18, 2013 at 10:30 AM, Lonni J Friedman wrote:
>
> >
> > 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 with resp
On Wed, Sep 18, 2013 at 2:02 AM, Kevin Grittner wrote:
> Lonni J Friedman 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
On Wed, Sep 18, 2013 at 2:02 AM, Kevin Grittner wrote:
> Lonni J Friedman 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
Lonni J Friedman 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 I've seen of THP
On Tue, Sep 17, 2013 at 3:47 PM, Andres Freund 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 9.3.0, and since t
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.
Thanks for your reply. Comments/answers inline below
On Tue, Sep 17, 2013 at 11:28 AM, Jeff Janes wrote:
> On Tue, Sep 17, 2013 at 11:22 AM, Lonni J Friedman
> wrote:
>>
>>
>> > c) What does logs say?
>>
>> The postgres server logs look perfectly normal, minus a non-trivial
>> slower run ti
On Tue, Sep 17, 2013 at 11:22 AM, Lonni J Friedman wrote:
>
> > 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.
>
Are you ge
On Tue, Sep 17, 2013 at 9:54 AM, Eduardo Morras wrote:
> On Tue, 17 Sep 2013 09:19:29 -0700
> Lonni J Friedman 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
On Tue, 17 Sep 2013 09:19:29 -0700
Lonni J Friedman 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 significant
> performanc
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 the
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 (f
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
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 ?S
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
>>> postgresq
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
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 server
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
.
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"
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
# IPv
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 127.0.0
On Wed, Jul 25, 2012 at 11:42 AM, Merlin Moncure wrote:
> On Wed, Jul 25, 2012 at 10:48 AM, BJ Freeman 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 U
On Wed, Jul 25, 2012 at 10:48 AM, BJ Freeman 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 server throu
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 AM:
On Wed, Jul 25, 2012 at 9:57 AM, BJ Freeman 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 server running
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
On 2012-03-12, Carson Gross 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 the size of this t
On Wed, Mar 14, 2012 at 2:34 PM, John R Pierce wrote:
> On 03/14/12 12:53 PM, Scott Marlowe wrote:
>>
>> Note that if you don't need a lot of storage you can often use 300G
>> 15k SAS drives which are around $300 each. 20 of those in a RAID-10
>> gives you ~3TB of storage which is plenty for most
On 03/14/12 12:53 PM, Scott Marlowe wrote:
Note that if you don't need a lot of storage you can often use 300G
15k SAS drives which are around $300 each. 20 of those in a RAID-10
gives you ~3TB of storage which is plenty for most transactional
applications.
I'm actually using 25 x 146gb 15k SAS
On Wed, Mar 14, 2012 at 1:41 PM, John R Pierce wrote:
> 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.
>
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 Net
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 onl
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 buil
1 - 100 of 324 matches
Mail list logo
