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
Hello, All!
I'm planing to upgrade from 7.2.1 to 7.3.4.
Will pg_dumpall and pg_restore be sufficient for propper data migration?
Mark
---(end of broadcast)---
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nom
Hekko, All!
I'm planing to upgrade from 7.2.1 to 7.3.4.
Will pg_dumpall and pg_restore be sufficient for propper data migration?
Mark
---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
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
Is it generally considered safe to upgrade libs and bins without
upgrading data -> ie I am running 7.0.1 and want to go to 7.0.2 without
touching my data dir? can I compile and install without worry of
touching my data?
I want to report a problem...
... i am a newbie with Linux system and i barely know his structure.
I installed Linux Red Hat and during the installation i choose to install
php and pgsql. After some initial problem to discover the directory where
the pgsql was installed all worked well but then
We are still running 7.1.3. Can anyone
highlight the big differences or reasons to upgrade? Is there some documentation
on this?
Thanks
Jodi
___Jodi
L KanterBioInformatics Database AdministratorUniversity of
Virginia(434) 924-2846[EMAIL PROTECTED]
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
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
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.
--
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
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
probably, though do it on a test machine first as sometimes little
issues can crop up.
Robert Treat
On Thu, 2003-09-04 at 08:06, Martins Zarins wrote:
> Hekko, All!
>
> I'm planing to upgrade from 7.2.1 to 7.3.4.
> Will pg_dumpall and pg_restore be sufficient for propper data migration?
>
> Mar
Martins Zarins writes:
> I'm planing to upgrade from 7.2.1 to 7.3.4.
> Will pg_dumpall and pg_restore be sufficient for propper data migration?
If you use pg_dumpall, then you need to restore using psql; pg_restore
won't do you any good.
Also: save your configuration files, read the release note
Hi,
What's the best way to upgade PostgreSQL on say a 6 machine cluster.
As I have compiled Pg from source must I compile Pg on each machine
again by hand
or can I compile once and send a package, .deb/.rpm, to each machine ?
Lets say all 6 machines have identical hardware and are all on a
192
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
Dear Sir/Madam,
After Upgrade Database to the latest version I got some problem like this
1. ODBC connection
I used to link table from postgresql to my database file (MS
Access) but now I cannot and it gives me error "Invalid field definition
'accont' in definition of index or relationsh
I have a large database. I had PG 7.0. I did the data dump and got a 2.5 GB
file. But when I tried to run psql with the new 7.1.2 I get a file to large
error and nothing happens psql exits.
Is there a limit with psql? I am hoping it was compiled wrong. I insted from
the binary RPMS for Mandrak
We are currently using Postgresql 7.1.2, running on a E3500 server, OS
Solaris 2.6. We would like to upgrade to postgresql 7.2.
1) Do you all consider it stable enough now to upgrade?
2) If I understand correctly, to upgrade, step would be:
a) pg_dumpall
b) reset PGHOME t
Ciao Gianmarco;
You can upgrade your pg installation by using the rpm version.
download the rpm version, the latest at the moment could be the 7.2, and
try to upgrade your intstallation using the RPM command.
p.s. man rpm
--
Auri
On Fri, 12 Apr 2002, Gianmarco Piola wrote:
> I want to repor
Jodi Kanter <[EMAIL PROTECTED]> writes:
> We are still running 7.1.3. Can anyone highlight the big differences or rea=
> sons to upgrade? Is there some documentation on this?
The release notes always mention the main improvements. Quoting from
http://www.ca.postgresql.org/users-lounge/docs/7.2/p
ge your queries to use separate LIMIT and OFFSET
clauses, e.g. LIMIT 10 OFFSET 20.
-Original Message-From:
[EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of Jodi
KanterSent: 13 May 2002 15:39To: Postgres Admin
ListSubject: [ADMIN] upgrade?
We are still running
The whole "vaccuum" concept is, IMHO, one of the weakest aspects of
PostgreSQL.
Speaking of which, we love Postgresql, but I am concerned about the fact
that major upgrades require unloading and reloading the database. We are
small enough now, so it is not really a concern. I cannot imagin
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
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
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
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
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
"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?
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
Hello,
The link http://www.ca.postgresql.org/docs/momjian/upgrade_tips_7.3 is no
longer valid.
Where i can found this tips?
Thanks,
Sergio Pili
---(end of broadcast)---
TIP 9: the planner will ignore your desire to choose an index scan if your
Hello,
I read a mail in the achive from Andrey V Khavryutchenko
<[EMAIL PROTECTED]> , dated in 01 Dec 1998 12:06:24 +0200, with
subject : recovering data from pgsql 6.1 installation
Since there's no answer to his question in the archives, I'm
posting the same problem here.
I us
Naomi Walker wrote:
> We are currently using Postgresql 7.1.2, running on a E3500 server, OS
> Solaris 2.6. We would like to upgrade to postgresql 7.2.
>
> 1) Do you all consider it stable enough now to upgrade?
>
> 2) If I understand correctly, to upgrade, step would be:
>
>a) pg_
> > > If so, that seems pretty drastic. I cannot imagine that once our
> > databases
> > > start getting really huge that this will last as an upgrade method. I
> > > thought we would be using pg_upgrade, but I see a note that it will not
> > > work with versions of postgres 7.1 and higher.
> >
At 01:53 PM 2/8/02 -0500, Bruce Momjian wrote:
>Naomi Walker wrote:
> > We are currently using Postgresql 7.1.2, running on a E3500 server, OS
> > Solaris 2.6. We would like to upgrade to postgresql 7.2.
> >
> > 1) Do you all consider it stable enough now to upgrade?
> >
> > 2) If I understand cor
Bruce Momjian <[EMAIL PROTECTED]> writes:
>> Bruce, are you saying I can use /contrib/pg_upgrade for my 7.1.2 to 7.2
>> upgrade?
> Yes, absolutely. At least it worked in my tests.
However, it'd be folly not to make a dump beforehand, so you can recover
if it doesn't work ...
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> >> Bruce, are you saying I can use /contrib/pg_upgrade for my 7.1.2 to 7.2
> >> upgrade?
>
> > Yes, absolutely. At least it worked in my tests.
>
> However, it'd be folly not to make a dump beforehand, so you can recover
> if it doe
Chad R. Larson wrote:
> At 11:53 AM 2/8/2002 , Bruce Momjian wrote:
> >It is in /contrib/pg_upgrade now and it does work for 7.1 upgrades,
> >though it is only lightly tested.
>
> When you say "work for 7.1 upgrades" I assume you mean like from 7.1.2 to
> 7.1.3. Is there a 7.1.2 to 7.2 version?
Chad, hold up a bit. Bruce and I are talking, and i'm asking the same things.
At 02:27 PM 2/8/02 -0700, Chad R. Larson wrote:
>At 11:53 AM 2/8/2002 , Bruce Momjian wrote:
>>It is in /contrib/pg_upgrade now and it does work for 7.1 upgrades,
>>though it is only lightly tested.
>
>When you say "w
I want to upgrade postgreql from version 6.5 to version 7.2.1 on a Debian
2.2 potatoe server has anyone had any experience with this.
[EMAIL PROTECTED]
---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Could anyone tell me what (if anything) I can do if I upgraded from 7.1.3 to
7.2, without doing backup (pg_dump). I cannot read my dataset because it is
incompatible with new version. Could you give me the commands?
I have Red Hat 7.3 (running SQL Ledger)
my data set is at: /usr/local/www/sql-
> Speaking of which, we love Postgresql, but I am concerned about the fact
> that major upgrades require unloading and reloading the database. We
are
> small enough now, so it is not really a concern. I cannot imagine this
> happening with really large database clusters (>50-100gigs).
>
> I know
"Steve Wolfe" <[EMAIL PROTECTED]> writes:
>> I know for minor releases, there are upgrade programs to let this happen
>> in
>> place. Is there any plan for not always having to load and reload in
>> the
>> future?
> It can be a pain in the butt, but I'm glad that it's done that way. I'd
> rath
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.
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
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.
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
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
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
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.)
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
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
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
While reading FAQ at
http://www.ca.postgresql.org/docs/faq-english.html#3.10, the following
advice is given:
"The PostgreSQL team makes only small changes between minor releases,
so upgrading from 7.2 to 7.2.1 does not require a dump and restore.
However, major releases (e.g. from 7.2 to 7.3) ofte
Well, since I am posting I might as well ask two questions..
FIrst, when I upgraded from 6.2.1 to 6.3.2 I performed a pg_dumpall and
after I did an import of the db.out.. All seemed okay, and I assumed
that permissions were okay, but I was wrong.
I was able to log in under postgres user, and the
> Hello,
>
> I read a mail in the achive from Andrey V Khavryutchenko
> <[EMAIL PROTECTED]> , dated in 01 Dec 1998 12:06:24 +0200, with
> subject : recovering data from pgsql 6.1 installation
> Since there's no answer to his question in the archives, I'm
> posting the same problem he
Well yes, but that don't help him any...
What you need is to re-install 6.1, do a dump, then upgrade. As you
know this then I take it that the real problem is that you no longer
have a copy of the souce.
For the souce maybe one of the developers can make a tar ball of 6.1
from CVS for you, or m
On Thu, 15 Apr 1999, Terry Mackintosh wrote:
> Well yes, but that don't help him any...
>
> What you need is to re-install 6.1, do a dump, then upgrade. As you
> know this then I take it that the real problem is that you no longer
> have a copy of the souce.
>
> For the souce maybe one of the
I have 6.2.1 if it would be of any help.
-Jay
> Neither are options :( We didn't start *properly* tagging things until
> well after v6.1, so you can't just pull a 6.1 version out :( That was one
> of things I was gonna try with the v6.3 problem awhile back...
>
> For this, someone is gonna hav
If you still have the need for 6.1, I found 6.1 and 6.1.1 on an old
file server or ours that is in the process of being retired.
fulcrum# ls -al postgres*
-rw-r--r-- 1 root 2626603 Oct 31 1997 postgresql-6.2.1.tar.gz
-rw-r--r-- 1 root 2610875 Oct 2 1997 postgresql-6.2.tar.gz
-rw-r-
Can I get copies of those?? :)
On Fri, 16 Apr 1999, Mike Embry-RZAW80 wrote:
> If you still have the need for 6.1, I found 6.1 and 6.1.1 on an old
> file server or ours that is in the process of being retired.
>
> fulcrum# ls -al postgres*
> -rw-r--r-- 1 root 2626603 Oct 31 1997 postgre
Hi Scott,
You must dump and reload the data
when upgrading from 7.1.x to 7.2.x
I feel i had read like that in the release notes
for 7.2.x
are u facing any problem in pg_dumping ??
regds.
mallah.
On Tuesday 21 May 2002 04:12 pm, Scott Taylor wrote:
> Could anyone tell me what (if anything) I
Scott Taylor <[EMAIL PROTECTED]> writes:
> Could anyone tell me what (if anything) I can do if I upgraded from 7.1.3 to
> 7.2, without doing backup (pg_dump). I cannot read my dataset because it is
> incompatible with new version. Could you give me the commands?
You're going to have to reinstal
Hello all!
I would like to ask what would be the best procedure to upgrade to a
new version of PostgreSQL in a production system when there is a 'initdb'
necessary?
Situation:
We are running PostgreSQL in a production system. There are about 1000
selects and about 100 inserts per minute.
To u
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 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
...@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
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
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
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 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
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
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.
"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
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.
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,
> Is a dump/restore required from 7.2 to 7.2.3? What if we were to go
> from 7.2 to 7.2.4, or even from 7.2 to the latest, 7.3.2? How can we
> tell when a dump/restore is required?
In answer to my own question, I found that the HISTORY file within the
source archive
(http://www.ca.postgresql.or
On 10 Feb 2003, Stephane Charette wrote:
> "The PostgreSQL team makes only small changes between minor releases,
> so upgrading from 7.2 to 7.2.1 does not require a dump and restore.
This says that you don't need to dump/restore when you are just upgrading
7.2 => 7.2.4, or 7.3.1 => 7.3.2. Minor r
I'm trying to avoid having to install 7.3, dump 7.2 and reload 7.3, then
install 7.4, dump 7.3 and install to 7.4 ... What's the chances of just using
the 7.4 pg_dumpall on the 7.2 database and having it work 100% ?
Also, I recall that when upgrading from 7.2 to 7.3 there was something that had
t
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
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
> Well, since I am posting I might as well ask two questions..
>
> FIrst, when I upgraded from 6.2.1 to 6.3.2 I performed a pg_dumpall and
> after I did an import of the db.out.. All seemed okay, and I assumed
> that permissions were okay, but I was wrong.
> I was able to log in under postgres us
I don't have any good news for you. Yes, you can set up a server on a
different port and perform a dump and reload while both systems are up,
but as you say, you are going to miss inserts during the dump because
pg_dump takes a snapshot when it starts.
My only suggestion is to keep the old data
On 10 Oct 2002 at 9:46, Reiner Dassing wrote:
> To upgrade to PostgreSQL 7.2.3 there is an 'initdb' necessary.
This caused me to ask around off-list. An initdb is required only if
you are upgrading from from pre-7.2.X.
--
Dan Langille
I'm looking for a computer job:
http://www.freebsddiary.or
On Thu, Oct 10, 2002 at 09:46:14AM +0200, Reiner Dassing wrote:
> Hello all!
>
> I would like to ask what would be the best procedure to upgrade to a
> new version of PostgreSQL in a production system when there is a 'initdb'
> necessary?
>
> Situation:
> We are running PostgreSQL in a productio
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
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
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:
> 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:
>> 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
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 "
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
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
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
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,
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
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
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
1 - 100 of 157 matches
Mail list logo
