...@pinelabs.com
Subject: Re: [ADMIN] Upgrade from 8.4
On Thu, Apr 18, 2013 at 2:10 PM, Rajiv Kasera
wrote:
I am planning to upgrade my Postgres DB server from v8.4 to a newer version.
Should 9.2 be a good choice for upgrading, it has the best features around
replication. Also can someone help
I recently upgraded from the 8.2 branch to 9.2. Since mine was so old the
only option I had was the dump/restore functionality, but that's really a
simple procedure, just potentially time consuming based on your data and
computers. It's also good to look over the release notes between the
version
Yes, PostgreSQL 9.2 would be an excellent choice; There are various upgrade
options available like dump/restore, slony and pg_upgrade where each have
their pros and cons. The selection of upgrade method solely depend upon the
data size and available downtime. It's strongly recommended to test upgra
I am planning to upgrade my Postgres DB server from v8.4 to a newer version.
Should 9.2 be a good choice for upgrading, it has the best features around
replication. Also can someone help me with a guide for the upgrade process
and rollback process in case anything fails.
Thanks,
Rajiv
smime.
Rafael --
<...>
>> Has anyone else seen anything like this ?
>>
>
> Hello
>
> The release notes for 9.2.2 say this:
>
> "... However, you may need to perform REINDEX operations to correct
> problems in concurrently-built indexes, as described in the first
> changelog item below."
>
> Bu
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 12/20/2012 12:06 PM, Greg Williamson wrote:
> Dear peoples,
>
>
> Today we upgraded a small (7.5 megabytes) but hyperactive database
> from postgresql 9.1.6 to 9.1.7 (we use INDEX CONCURRENTLY a lot)
> and after restarting it looks as if we have
Dear peoples,
Today we upgraded a small (7.5 megabytes) but hyperactive database from
postgresql 9.1.6 to 9.1.7 (we use INDEX CONCURRENTLY a lot) and after
restarting it looks as if we have a slower system -- fewer queries, but more
long ones, fewer checkpoints. I am still manually comparing c
In the documentation, it states we need to drop and recreate the
information schema.
A simple drop did not work (it required drop/cascade).
Executed the information_schema.sql. I see an entry (when using pgAdmin)
for the information_schema under the Catalogs, but I do not see any
catalog objects.
Rudolf van der Leeden wrote:
> Hi,
>
> upgrading Postgres 9.0.5 to 9.1.1 is done using:
>
> - pg_upgrade
> - CREATE EXTENSION citext FROM unpackaged (using the latest patch)
>
> This works fine even for indexes on citext columns.
> The problem comes with an index on LOWER(citext), e.g. the ind
Hi,
upgrading Postgres 9.0.5 to 9.1.1 is done using:
- pg_upgrade
- CREATE EXTENSION citext FROM unpackaged (using the latest patch)
This works fine even for indexes on citext columns.
The problem comes with an index on LOWER(citext), e.g. the index
idx_lower_login
has been created on column '
fel wrote:
> I have a small server running RHEL 5.2 32bit / Postgresql 8.3.3.
> I would like to upgrade Postgres to 9.0 on a new server running
> RHEL 5.5 but 64bit.
>
> What would be the best solution :
> - Dump data from 32bit to 64bit then upgrade to v9.0 (using
> pg_upgrade).
> - Upgrade
Hello all,
I would need advice regarding upgrade.
I have a small server running RHEL 5.2 32bit / Postgresql 8.3.3.
I would like to upgrade Postgres to 9.0 on a new server running RHEL 5.5
but 64bit.
What would be the best solution :
- Dump data from 32bit to 64bit then upgrade to v9.0 (using
Gabriele Bartolini ha scritto:
Ciao Silvio,
On Tue, 13 Jul 2010 22:52:51 +0200, Iñigo Martinez Lasala
You should script database migration process in order to make it faster.
Upgrading binaries is really simple. A yum upgrade should be enough.
Yes, faster and repeatable. Something you
Ciao Silvio,
On Tue, 13 Jul 2010 22:52:51 +0200, Iñigo Martinez Lasala
> You should script database migration process in order to make it faster.
> Upgrading binaries is really simple. A yum upgrade should be enough.
Yes, faster and repeatable. Something you can launch with a script that
does eve
lumn WHERE value='12'::integer).
By the way, why not migrate to 8.4? You will find same problems that
with 8.3 and has better performance. Parallel restore in 8.4 is
fantastic.
-Original Message-
From: Silvio Brandani
To: pgsql-admin@postgresql.org
Subject: [ADMIN] upgrade postgres 8.1
2010/7/13 Silvio Brandani :
> We need to upgrade the postgres running on our production system under Red
> Hat Enterprise Linux Server release 5.1 from version 8.1.21 to version
> 8.3.6.
>
> we could have a stop/maintenance window of 3/4 our the sum of size of
> databases is around 1G .
> Which i
Am Dienstag 13 Juli 2010 11:30:20 schrieb Silvio Brandani:
> We need to upgrade the postgres running on our production system under
> Red Hat Enterprise Linux Server release 5.1 from version 8.1.21 to
> version 8.3.6.
Have a look here:
http://wiki.postgresql.org/wiki/RPM_Installation#How_do_I_per
We need to upgrade the postgres running on our production system under
Red Hat Enterprise Linux Server release 5.1 from version 8.1.21 to
version 8.3.6.
we could have a stop/maintenance window of 3/4 our the sum of size of
databases is around 1G .
Which is the best practice to execute such u
On Thu, May 13, 2010 at 09:31:27AM -0500, Kevin Grittner wrote:
> Ray Stell wrote:
> > ,3440,,2010-05-13 09:06:35.734 EDT,4bebf95b.d70,5,2010-05-13
> > 09:06:35 EDT,0,FATAL: could not restore file "0002.history"
> > from archive: return code 32512
>
> Return code 32512? I think you'd be OK
Ray Stell wrote:
> ,3440,,2010-05-13 09:06:35.734 EDT,4bebf95b.d70,5,2010-05-13
> 09:06:35 EDT,0,FATAL: could not restore file "0002.history"
> from archive: return code 32512
Return code 32512? I think you'd be OK if your recovery script
returned 1 when it didn't find this file.
-Kevin
On Tue, May 11, 2010 at 04:29:18PM +0300, Devrim G?ND?Z wrote:
> On Tue, 2010-05-11 at 09:16 -0400, Ray Stell wrote:
> > What are the steps for upgrade of a primary/PITR standby pair to the
> > latest 8.3 patchset, 8.3.6-8.3.10? I don't see this in the docs.
> > Should there be something added t
On Tue, 2010-05-11 at 09:16 -0400, Ray Stell wrote:
> What are the steps for upgrade of a primary/PITR standby pair to the
> latest 8.3 patchset, 8.3.6-8.3.10? I don't see this in the docs.
> Should there be something added to 15.4. Upgrading?
>
> My guess is:
> 1. turn off the standby confi
What are the steps for upgrade of a primary/PITR standby pair to the
latest 8.3 patchset, 8.3.6-8.3.10? I don't see this in the docs.
Should there be something added to 15.4. Upgrading?
My guess is:
1. turn off the standby config in primary
2. upgrade primary
3. rebuild standby
That way you
Hi
Further to David Jantzen's post of 3/16/2010.
We have decided to try to upgrade the database software from our old custom
8.3.7 instance to the std upstream 8.3.10 version.
We have no hash indexes on interval types; we therefore anticipate that the
migration will be a shutdown of the old ins
Indexes are created as B-tree type unless you explicitly call for
another type when creating the index. I get the impression that other
index types are not commonly used in most applications.
If you look at the index definition using, say, psql from the command
line, or a graphical tool like
I need to upgrade postgresql from 8.1.11 to 8.1.18.
The documentation states to
REINDEX all GiST indexes and REINDEX hash indexes on interval columns after the
upgrade.
I googled the two items only to find the same comment with no instructions on
what they are or how to do it.
How can I check if
Thank you , that worked!
Isabella
Ray Stell wrote:
btw, no dump is required to flip from 8.3x to 8.3x, but
testing is a good thing.
check the postmaster.pid
[postgre...@swallowtail alerts_oamp]$ cat postmaster.pid
2545
/var/database/pgsql/alerts_oamp
5478001 0
alerts_oamp]$ ps -ef
btw, no dump is required to flip from 8.3x to 8.3x, but
testing is a good thing.
check the postmaster.pid
[postgre...@swallowtail alerts_oamp]$ cat postmaster.pid
2545
/var/database/pgsql/alerts_oamp
5478001 0
alerts_oamp]$ ps -ef | grep 2545
500 2545 1 0 Jan11 ?00:0
Hi All,
I'm testing for the first time a PG upgrade process, presently running
8.3.4 and try to upgrade to 8.3.6. I have installed 8.3.6 in separate dir
- run pg_dumpall using the new PG 8.3.6 version
- shutdown the server
- create a new db cluster with 8.3.6 initdb
-copy pg_gba.conf and pos
On Sun, Dec 7, 2008 at 1:23 PM, Gerd Koenig <[EMAIL PROTECTED]> wrote:
> Hello,
>
> we're planning an upgrade from Postgres 8.3.1 to latest 8.3.5 via rpm
> (Opensuse 10.3 - 64bit).
> Is it really that simple ?
>
> 1.) stop cluster (e.g. pg_ctl stop)
> 2.) perform the upgrade (rpm -Uvh *.rpm)
> 3.)
Hello,
we're planning an upgrade from Postgres 8.3.1 to latest 8.3.5 via rpm
(Opensuse 10.3 - 64bit).
Is it really that simple ?
1.) stop cluster (e.g. pg_ctl stop)
2.) perform the upgrade (rpm -Uvh *.rpm)
3.) start the cluster (pg_ctl start)
thanks in advanceGERD.
--
Sent via pgsql
On Thu, October 16, 2008 06:47, Carol Walter wrote:
> Let me see if I understand this correctly.
> Always do a backup before doing any destructive sys admin functions. =)
> First, I run configure, taking care to make sure all the options point
> to the right places.
> Second, I run gmake
> Third,
Let me see if I understand this correctly.
Always do a backup before doing any destructive sys admin functions. =)
First, I run configure, taking care to make sure all the options point
to the right places.
Second, I run gmake
Third, I run gmake install.
Thanks,
Carol
On Oct 14, 2008, at 1:2
Evan Rempel wrote:
> What this means is that you do not have to "update" the data repository
> (wherever your
> postgresql database is stored). All that needs to be done is to uninstall the
> old version,
> and install the new version. Start the new version and use the data where it
> sits.
Act
What this means is that you do not have to "update" the data repository
(wherever your
postgresql database is stored). All that needs to be done is to uninstall the
old version,
and install the new version. Start the new version and use the data where it
sits.
Now, that all sound fine when I s
What this means is that you do not have to "update" the data repository
(wherever your
postgresql database is stored). All that needs to be done is to uninstall the
old version,
and install the new version. Start the new version and use the data where it
sits.
Now, that all sound fine when I s
What this means is that you do not have to "update" the data repository
(wherever your
postgresql database is stored). All that needs to be done is to uninstall the
old version,
and install the new version. Start the new version and use the data where it
sits.
Now, that all sound fine when I s
Hello,
I'm doing an upgrade from 8.2.4 to 8.2.10. The documentation says,
"When you update between compatible versions, you can simply replace
the executables and reuse the data directory on disk." I guess I
don't quite understand what this means. Replace them by running some
parts of
I think I just made a huge error. I just upgraded all of my systems and in
the process I just upgraded the data base from 8.1 to 8.3. At least I think
it was 8.1. Anyway the postmaster won't run and I can't backup the old
database without a hue effort. Is there a way around this or do I have to
On Thu, Jul 24, 2008 at 1:51 PM, Chris Bovitz
<[EMAIL PROTECTED]> wrote:
>
>
> Does it matter which version - 8.3.3 or 8.2.9 - we install on our client
> boxes? Is the client-side backwards compatible? Or should we install both
> and have a wrapper for the "psql" script to detect which database w
Scott Marlowe wrote:
On Thu, Jul 24, 2008 at 9:00 AM, Chris Bovitz
<[EMAIL PROTECTED]> wrote:
We have 8.1.3 on our operational and development database servers and will
upgrade to 8.3.3 (development) and 8.2.9 (operations) soon. (We will not
upgrade both systems' databases now be
On Thu, Jul 24, 2008 at 9:00 AM, Chris Bovitz
<[EMAIL PROTECTED]> wrote:
> We have 8.1.3 on our operational and development database servers and will
> upgrade to 8.3.3 (development) and 8.2.9 (operations) soon. (We will not
> upgrade both systems' databases now because we've already tested 8.2 on
We have 8.1.3 on our operational and development database servers and
will upgrade to 8.3.3 (development) and 8.2.9 (operations) soon. (We
will not upgrade both systems' databases now because we've already
tested 8.2 on our web server database for the past year, so it's already
spent time in "
Tom Lane wrote:
> Jesper Krogh <[EMAIL PROTECTED]> writes:
>> Tom Lane wrote:
>>> Drop the constraints in the source database.
>
>> That would be my workaround for the problem. But isn't it somehow
>> desirable that pg_dumpall | psql "allways" would work?
>
> Well, sure. The reason why this sort
Jesper Krogh <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> Drop the constraints in the source database.
> That would be my workaround for the problem. But isn't it somehow
> desirable that pg_dumpall | psql "allways" would work?
Well, sure. The reason why this sort of thing is deprecated is e
Tom Lane wrote:
> Jesper Krogh <[EMAIL PROTECTED]> writes:
>> The tables are running a "home-made" timetravelling feature where a
>> contraint on the table implements the foreing keys on the table.
>
> You mean you have check constraints that do selects on other tables?
Yes. We do.. we have to ..
Jesper Krogh <[EMAIL PROTECTED]> writes:
> The tables are running a "home-made" timetravelling feature where a
> contraint on the table implements the foreing keys on the table.
You mean you have check constraints that do selects on other tables?
You have just found out (one reason) why that's a b
We have a quite large (in our measurements) database, currently around
150GB of data.
Time has come to upgrade to 8.2.5 from 8.1.10. Going to the fine
manual.. having a system where both databases are installed PG8.1 on
port 5432 and PG8.2 on port 5433, logging in as the "postgres" user and
runnin
On Sun, 24 Jun 2007, Campbell, Lance wrote:
In order to upgrade from 8.1.4 to 8.1.9 I get the impression from the
documentation I should do the following:
1) stop my database
2) back it up (just for safety purposes)
3) install the new version overtop of the old one (I would
In order to upgrade from 8.1.4 to 8.1.9 I get the impression from the
documentation I should do the following:
1) stop my database
2) back it up (just for safety purposes)
3) install the new version overtop of the old one (I would
actually rename the install directory of 8.1
Thanks all. The only problem that I had was the unicode stuff, and that needed
cleaning up anyway so I'm not too worried. I've at least managed to get this
database on it's own tablespace ( hint: when outsourcing development to a
company you never met, you may well be paying a bunch of schoolkid
Thanks, I knew about that one, and spent half a day cleaning up the data set
before transfer.
That was exciting...
Cheers, Steve
On Thu, 10 May 2007 08:57:25 -0600
Dan Harris <[EMAIL PROTECTED]> wrote:
> Steve Holdoway wrote:
> > Are there any gotchas? I've got the opportunity to move to anoth
I almost forgot one of the biggest gotchas. Remember that users and
groups were conflated into "roles" in postgres 8.1. In addition to being
a change, there were some other issues, namely that you couldn't
manually specify user and group sysids. I had to change our user and
group management scr
A few months ago, I upgraded postgres from 7.4 to 8.2. There were a few
gotchas, but we don't keep a whole lot of data so even the biggest problems
were, on the whole, minor.
- The cidr data type became more strict, and a few tables in our network
database would not restore until this was fixed.
Steve Holdoway wrote:
Are there any gotchas? I've got the opportunity to move to another database
server for this application and yould like to take the opportunity to upgrade
at the same time.
Yes. One of them that got me was that in 8.0.x, you could insert "invalid"
unicode byte sequences
Are there any gotchas? I've got the opportunity to move to another database
server for this application and yould like to take the opportunity to upgrade
at the same time.
tia,
Steve
---(end of broadcast)---
TIP 7: You can help support the Postgr
Ray Stell <[EMAIL PROTECTED]> writes:
> 2. When you prepare to pg_dumpall using the new version, do you need to
> change all the
>path vars to point to the new install such as LD_LIBRARY_PATH and PATH, or
> does just
>an explicit call of the new pg_dumpall ok?
Just call the new version
On Wed, Jan 17, 2007 at 01:31:50PM -0800, Jeff Frost wrote:
Please, a couple of more questions about this upgrade process (never been
through it, obviously).
1. I am backing up some of the config files that I know that I have touched:
postgresql.conf, pg_hba.conf
Are there other fil
I apologize; I had intended to reply-all, and simply missed the mark somehow.
Also, thank you for the link to the documentation; it was clear enough that I
was able to get what I needed done...at least as far as I can tell, since it's
not finished yet.
Thank you very much for your g
On Wed, 17 Jan 2007, Ray Stell wrote:
On Wed, Jan 17, 2007 at 01:18:06PM -0800, Jeff Frost wrote:
On Wed, 17 Jan 2007, Ray Stell wrote:
Why is there pg_dumpall instead of a pg_dump with some flag?
pg_dumpall does all DBs plus the globals, but I'll have to let one of the
developers answer why
On Wed, Jan 17, 2007 at 01:18:06PM -0800, Jeff Frost wrote:
> On Wed, 17 Jan 2007, Ray Stell wrote:
> >Why is there pg_dumpall instead of a pg_dump with some flag?
>
> pg_dumpall does all DBs plus the globals, but I'll have to let one of the
> developers answer why there isn't just a flag for pg_
On Wed, 17 Jan 2007, Ray Stell wrote:
1. Curious about the difference in step 6 of this list, uses pg_restore, and
what is listed in the doc:
http://www.postgresql.org/docs/8.2/interactive/install-upgrading.html
which says to restore via:
psql -d postgres -f outputfile
It depends
Please reply-all when replying so everyone can help.
What I mean is that I have a physical server db1 which is old and meant to be
replaced by new shiny physical server db2.
Let me ask a different question, because it seems perhaps I didn't understand
your original email.
Are you just tryin
1. Curious about the difference in step 6 of this list, uses pg_restore, and
what is listed in the doc:
http://www.postgresql.org/docs/8.2/interactive/install-upgrading.html
which says to restore via:
psql -d postgres -f outputfile
Is this use of psql related to the fact that a pg
And of course, I should have made mention of the docs here:
http://www.postgresql.org/docs/8.1/interactive/migration.html
because it likely explains it better than I am. :-)
On Wed, 17 Jan 2007, Jeff Frost wrote:
You have to dump the original 7.4.9 version of the database and restore that
int
You have to dump the original 7.4.9 version of the database and restore that
into the 8.1.3 database server.
An example:
I have a server db1 which is running pg 7.4.9
I have a server db2 which is to replace db1 running pg 8.1.3
I would likely just do something like this from db2 (assuming no c
Please clear something up for me. The database I'm trying to upgrade was/is
empty; only the original installation was present, no tables. Exactly what is
it I'm supposed to be dumping? If you mean making a copy of the original
8.1.3, that I've done before, but I'm unclear as to the meaning of
Andrew,
If you're moving between major versions, a dump/restore is necessary. The
proper procedure is:
1) pg_dump the old database by using the new version of pg_dump (8.1.x)
against the old db server (7.4.9 in your case)
2) stop the old database server (and possibly move/rename the old dat
I was requested to load data (a full copy of the db in question) from one
postgres database into another (empty) db on another system. Both of these
systems are running SuSE 9.2 Linux, for the record. It turned out that the two
systems were running different versions of postgres; the first sys
Thusitha Kodikara <[EMAIL PROTECTED]> writes:
> We are testing upgrade from PostgreSQL version 7.3.9 to 7.4.9 on Gentoo
> linux. In some Java programs we get the error " SET AUTOCOMMIT TO OFF is no
> longer supported".
> I read about some changes in release notes
> "http://www.postgresql.org/do
Hi,We are testing upgrade from PostgreSQL version 7.3.9 to 7.4.9 on Gentoo linux. In some Java programs we get the error " SET AUTOCOMMIT TO OFF is no longer supported".I read about some changes in release notes "http://www.postgresql.org/docs/8.1/static/release-7-4.html". What is the best way to s
Hello all,
I am upgrading from postgresql v. 7.4 to 8.1. I dump my database in
plain text format and run the iconv command to fix the UTF8. When i
restore everything is populating but two tables. I was wondering if
anyone knows what would cause this. Thanks in advance.
Josh O'Brien
begin
On Thu, Jan 12, 2006 at 09:15:08AM -0500, Josh O'Brien wrote:
> I am upgrading from postgresql version 7.4 to 8.1 and i'm having a
> problem with pg_restore. It is not recognizing the \N command as
> inserting a null value. Does anyone know how to fix this?
Please post the exact commands you r
"Josh O'Brien" <[EMAIL PROTECTED]> writes:
> I am upgrading from postgresql version 7.4 to 8.1 and i'm having a
> problem with pg_restore. It is not recognizing the \N command as
> inserting a null value.
Doesn't seem very likely. What exactly did you do, and what results
are you getting?
Hello all,
I am upgrading from postgresql version 7.4 to 8.1 and i'm having a
problem with pg_restore. It is not recognizing the \N command as
inserting a null value. Does anyone know how to fix this?
Thanks in advance
begin:vcard
fn:Joshua O'Brien
n:O'Brien;Joshua
org:Zedx Inc.
title:Databa
Many thanks, Peter and Bricklen. That worked well.
---
Husam Tomeh
-Original Message-
From: Peter Eisentraut [mailto:[EMAIL PROTECTED]
Sent: Wednesday, November 30, 2005 6:46 AM
To: Tomeh, Husam
Cc: pgsql-admin@postgresql.org
Subject: Re: [ADMIN] upgrade database to 8.1 - 2GB file
Tomeh, Husam wrote:
I'm upgrading from 8.0 to 8.1 on RedHat 2.6 kernel. I'm hitting the file
max limit of 2 GB file when I pg_dump my database (even if I compress
the dump file as it gets generated using a pipe). pg_dump is the
recommendation stated in the INSTALL doc to upgrade; what would be
Am Mittwoch, 30. November 2005 15:17 schrieb Tomeh, Husam:
> I'm upgrading from 8.0 to 8.1 on RedHat 2.6 kernel. I'm hitting the file
> max limit of 2 GB file when I pg_dump my database (even if I compress
> the dump file as it gets generated using a pipe). pg_dump is the
> recommendation stated in
I'm upgrading from 8.0 to 8.1 on RedHat 2.6 kernel. I'm hitting the file
max limit of 2 GB file when I pg_dump my database (even if I compress
the dump file as it gets generated using a pipe). pg_dump is the
recommendation stated in the INSTALL doc to upgrade; what would be the
next recommendatio
Josh O'Brien wrote:
Hello all
I was just wondering if anyone could tell me if there is any seamless
way to upgrade from 7.4 to 8.1 without performing a full dump/restore.
Slony-I or Mammoth Replicator
Thanks
Joshua O'Brien
DBA
Zedx Inc.
--
On Fri, Nov 11, 2005 at 11:08:58 -0500,
Josh O'Brien <[EMAIL PROTECTED]> wrote:
> Hello all
>
> I was just wondering if anyone could tell me if there is any seamless
> way to upgrade from 7.4 to 8.1 without performing a full dump/restore.
If you need to minimize down time, there are ways to us
Hello all
I was just wondering if anyone could tell me if there is any seamless
way to upgrade from 7.4 to 8.1 without performing a full dump/restore.
Thanks
Joshua O'Brien
DBA
Zedx Inc.
begin:vcard
fn:Joshua O'Brien
n:O'Brien;Joshua
org:Zedx Inc.
title:Database Administrator
version:2.1
end:v
> instance of postgres. Is there a way to keep my production db up and
> running in 8.0.3 while I also run 8.1.0 on the same server? Then, I could
Yes. There is a way. You have to specify another location and
port for 8.1.0.
Luf
---(end of broadcast)-
Rafael Martinez Guerrero <[EMAIL PROTECTED]> writes:
> On Tue, 2005-11-08 at 18:23, Moises Alberto Lindo Gutarra wrote:
>> you only need make postgres 8.1.0 run using another port, example 5438
> Or another IP/address (listen_addresses) and the same port 5432. ;)
No, because both postmasters will
On Tue, 2005-11-08 at 18:23, Moises Alberto Lindo Gutarra wrote:
> you only need make postgres 8.1.0 run using another port, example 5438
>
Or another IP/address (listen_addresses) and the same port 5432. ;)
--
Rafael Martinez, <[EMAIL PROTECTED]>
Center for Information Technology Services
Univ
Dan,
Sure, just bring it up in a different directory and have it listen on a
different port. You could either dump/restore to get the data over to it or
use a replication tool such as slony or mammoth to do the deed. The latter
method has the benefit of keeping it up to date while you poke a
you only need make postgres 8.1.0 run using another port, example 5438
2005/11/8, Dan The Man <[EMAIL PROTECTED]>:
> Hi,
> I have enough resources on my 3 postgresql servers to run more than one
> instance of postgres. Is there a way to keep my production db up and
> running in 8.0.3 while I also
Hi,
I have enough resources on my 3 postgresql servers to run more than one
instance of postgres. Is there a way to keep my production db up and
running in 8.0.3 while I also run 8.1.0 on the same server? Then, I could
copy the data and support two databases until things looked good. Then,
"Patrick Brennan" <[EMAIL PROTECTED]> writes:
> Hopefully a simple question. I have a copy of the data from an old
> PostgreSQL installation (it's not a dump, it's a copy of the PGDATA
> directory). I have two questions, is there a simple way for me to
> determine the version of PostgreSQL tha
Hi there,
Hopefully a simple question. I have a copy of the data from an old
PostgreSQL installation (it's not a dump, it's a copy of the PGDATA
directory). I have two questions, is there a simple way for me to
determine the version of PostgreSQL that this data belongs to?
Secondly, is ther
Tom Lane wrote:
"Andrei Bintintan" <[EMAIL PROTECTED]> writes:
I use Suse Linux 9.1. Everything worked fine exept a single thing: YAST =
always says that libdb-4.1.so is required by postgresql server( I think =
it requires the db4.1).
Postgres does not use libdb at all.
No, but RPM does.
"Andrei Bintintan" <[EMAIL PROTECTED]> writes:
> I use Suse Linux 9.1. Everything worked fine exept a single thing: YAST =
> always says that libdb-4.1.so is required by postgresql server( I think =
> it requires the db4.1).
Postgres does not use libdb at all. Sounds to me like a packaging error
Hi,
I wanted to upgrade Postgre Server from 7.4 to
8.0. I downloaded the rpm's and made the upgrade.
I use Suse Linux 9.1. Everything worked fine exept
a single thing: YAST always says that libdb-4.1.so is required by postgresql server( I think it
requires the db4.1). I looked in the B
: Monday, November 01, 2004 12:27 PM
To: 'Tom Lane'
Subject: RE: [ADMIN] Upgrade from 7.3.4 to 7.4.6
Tom
Thanks for the reply, much appreciated. On-the-wire is a step in the right
direction. To get a bit more out of you regarding this issue, what exactly
is the correct method for receiv
"Cliff Reid" <[EMAIL PROTECTED]> writes:
> My instant analysis: It seems to not like BINARY CURSOR. When I remove
> BINARY from the SQL DECLARE string, I no longer receive the seg-fault but
> the data results (presentation) are not as expected.
7.4 changed the external representation in which BIN
Hello
Can anyone point me to or near the reason why my pg_dumpall of my 7.3.4 DB
and subsequent 7.4.6 psql restoration of that dump show up as a failure when
I run my programs against it. I am using libpq as the DB interface.
Program results are successful on the 7.3.4 system but I get seg-faults
erform the
upgrade I'll be pleased to know it ...
And sorry for my poor english ...
-- Mensaje original --
Date: Tue, 06 Jul 2004 11:06:25 +0200
From: Daniel Rubio <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
Subject: [ADMIN] Upgrade problems with OID type ...
Hi all!
I'm trying to upgrad
Hi all!
I'm trying to upgrade from 7.3.2 to 7.4.3 but I've a problem with a
database (1 I know, there could be more) containing a table with an oid
type field.
I run the migration doing:
../bin/pg_dumpall -o -p 5432 | /apps/pgs-7.4.3/bin/psql -d template1 -p
5433 1>/tmp/out 2>/tmp/err
The comm
On Thu, 13 May 2004, Jodi Kanter wrote:
> We are currently on version 7.3.3 and I was thinking of upgrading. Is
> the 7.4.2 version considered a stable version?
> I read some info regarding changes to the system tables. Can someone
> touch on how this might affect us?
> Do I need to restore my dat
We are currently on version 7.3.3 and I was thinking of upgrading. Is
the 7.4.2 version considered a stable version?
I read some info regarding changes to the system tables. Can someone
touch on how this might affect us?
Do I need to restore my database with this upgrade?
Thanks so much,
Jodi K
1 - 100 of 157 matches
Mail list logo
