me -h hostname
and import with pg_restore from 9.0 too.
-Original Message-
From: Adib
To: Iñigo Martinez Lasala
Cc: [email protected]
Subject: Re: [ADMIN] Problems Upgrading from 8.2 to 9.0
Date: Wed, 22 Dec 2010 01:51:53 -0800
Thanks for all the great advice.
In my case I hav
m table where integer='1'::integer
> so types match.
>
> Migrating from 8.2 to 8.3 and higher versions can be a hard task if you
> have to check lot of SQL code.
>
>
>
> -Original Message-
> *From*: Adib >
> *To*: Devrim GÜNDÜZ
>
> >
> *
im GÜNDÜZ
Cc: [email protected]
Subject: Re: [ADMIN] Problems Upgrading from 8.2 to 9.0
Date: Wed, 22 Dec 2010 00:01:14 -0800
I solved my problems by using the uninstall scripts located in the
share/contrib in 8.2 to get rid of tsearch2 and fuzzymatch and that
eliminated a lot of the errors I was
I solved my problems by using the uninstall scripts located in the
share/contrib in 8.2 to get rid of tsearch2 and fuzzymatch and that
eliminated a lot of the errors I was running into.
2010/12/21 Adib
> Is there some way to avoid restoring tsearch2 since full text searching is
> now part of pos
Is there some way to avoid restoring tsearch2 since full text searching is
now part of postgres 9.0, the apps that use the database don't do any full
text searching.
2010/12/21 Devrim GÜNDÜZ
> On Tue, 2010-12-21 at 22:39 -0800, Adib wrote:
> > ERROR: type "tsvector" is only a shell
> > ERROR:
On Tue, 2010-12-21 at 22:39 -0800, Adib wrote:
> ERROR: type "tsvector" is only a shell
> ERROR: operator class "gin_tsvector_ops" does not exist for access
> method
> "gin
*IIRC*, you need to load contrib/tsearch2.sql to database *before*
restoring your backup.
Regards,
--
Devrim GÜNDÜZ
Post
Hi,
I have a very old postgres 8.2 server which I want to upgrade to 9.0.2
server, the server are on different boxes and the 9.0.2 is fully running. I
think that my 8.2 contains tsreach2 which none of my applications use. The
postgres 8.2 is running on Windows 2003 server and 9.0.2 is running on
W
I have the problem and the solution now after much tears. The problem was that we had
managed to get ascii codes 13s into text fields in the source database. These were
being exported into the dump and this was making the COPY FROM stdin process throw a
wobbly.
We are now running an intermed
Sorry! Meant pg_dump to dump and cat myfile.txt | psql mydatabase to restore. I have
dumped just the offending table out as a separate file but this makes no odds. I seem
to recall that last time I tried pg_dump in compressed format under 7.1.3 it wouldn't
restore so I haven't tried that.
I
On Wed, Jul 07, 2004 at 04:28:53PM +0100, Hilary Forbes wrote: >
> ... when I run pg_dump to restore the data, one table with approx
> 5.5 million records gives me
>
> ERROR: invalid memory alloc request size 1073741824
What do you mean "pg_dump to restore the data"? One would normally use
psql
I have a 7.1.3 instance of postgres running on one machine and want to move the
database from that machine to a new machine running 7.4.1. We've installed 7.4.1 and
I have successfully run pg_dump on the 7.1.3 machine and transferred the file over.
However when I run pg_dump to restore the dat
thanks Geoffrey for posting the observation.
I hope you will soon find the answer to your
question on investigation.
regds
mallah.
On Thursday 06 February 2003 09:27 pm, Geoffrey Wossum wrote:
> On Thursday 06 February 2003 06:31 am, Rajesh Kumar Mallah wrote:
> > In my case the message "Inva
David Gilbert <[EMAIL PROTECTED]> writes:
> I find that the whole database dumps do not have 'create user' and
> 'create group' commands.
Those are dumped by pg_dumpall, but not by pg_dump. Since users and
groups span all databases in an installation, it wouldn't be very useful
for pg_dump to inc
> "Geoffrey" == Geoffrey Wossum <[EMAIL PROTECTED]> writes:
Geoffrey> Hi all, I have a database cluster running on PostgreSQL
Geoffrey> 7.1.3 compiled from source, on Debian Linux. I want to
Geoffrey> upgrade the cluster to PostgreSQL 7.3.x.
Geoffrey> In order to get the data over, I ran: PGU
Geoffrey Wossum <[EMAIL PROTECTED]> writes:
> Apparently PostgreSQL 7.1.3 didn't really enforce the length on VARCHAR(#)'s,
> which is why this never caused a problem with it.
Well, it did, but it did silent truncation instead of complaining.
This was determined to be not spec compliant ...
> Now
On Thursday 06 February 2003 06:31 am, Rajesh Kumar Mallah wrote:
> In my case the message "Invalid command \N" was coming
> during COPY command execution when some other SQL command had
> failed prior to COPY execution. ie the COPY command and data
> in that part were perfectly fine.
Ah, found m
ssum wrote:
> -- Forwarded Message --
>
> Subject: Re: [ADMIN] Problems upgrading from 7.1.3
> Date: Wednesday 05 February 2003 01:39 pm
> From: Geoffrey Wossum <[EMAIL PROTECTED]>
> To: "Bjoern Metzdorf" <[EMAIL PROTECTED]>
>
> On Wednesday 05 Febru
Hmmm I face the same problem and it got solved.
In my case the message "Invalid command \N" was coming
during COPY command execution when some other SQL command had
failed prior to COPY execution. ie the COPY command and data
in that part were perfectly fine.
how i came to know abt it was by r
Geoffrey Wossum <[EMAIL PROTECTED]> writes:
> On Wednesday 05 February 2003 01:12 pm, Tom Lane wrote:
>> This smells to me like it could be a newline-formatting problem (COPY is
>> pretty picky about its newlines).
> [ Nope ]
Drat, another perfectly good theory down the drain.
> Bjoern suggested
On Wednesday 05 February 2003 01:12 pm, Tom Lane wrote:
> Er, how did you copy the file over exactly?
scp
> This smells to me like it could be a newline-formatting problem (COPY is
> pretty picky about its newlines). If you passed the file through
> anything that might choose to convert Unix ne
-- Forwarded Message --
Subject: Re: [ADMIN] Problems upgrading from 7.1.3
Date: Wednesday 05 February 2003 01:39 pm
From: Geoffrey Wossum <[EMAIL PROTECTED]>
To: "Bjoern Metzdorf" <[EMAIL PROTECTED]>
On Wednesday 05 February 2003 11:36 am, you wrote:
&g
Geoffrey Wossum <[EMAIL PROTECTED]> writes:
> I then took that file over to test machine running PostgreSQL 7.3.1,
Er, how did you copy the file over exactly?
This smells to me like it could be a newline-formatting problem (COPY is
pretty picky about its newlines). If you passed the file through
> I got lots of errors about "Invalid command \N" in the COPY xxx FROM
> statements, and most of the tables were completely empty.
Try dumping with -d or -D:
-d, --insertsdump data as INSERT, rather than COPY, commands
-D, --column-inserts dump data as INSERT commands with column
Hi all,
I have a database cluster running on PostgreSQL 7.1.3 compiled from source, on
Debian Linux. I want to upgrade the cluster to PostgreSQL 7.3.x.
In order to get the data over, I ran: PGUSER=postgres
/usr/local/pgsql/bin/pg_dumpall > survey1.sql on the production machine
running 7.1.3.
James Moore <[EMAIL PROTECTED]> writes:
> Yesterday I attempted to upgrade a system running 7.1 beta4 RPMS that I
> built from the SRPM to 7.1.0 RPMS built from the SRPMS. I assumed that
> since the version number difference was minor I wouldn't have a
> problem
If you're going to run beta relea
We were running postgresql 6.4 on a Linux RedHat 6.0 Intel machine. Someone
decided to upgrade the version to 6.5.3 , and went ahead and just grabbed
the rpms and installed them, not knowing you had to dump the databases. The
system ran for about a week before someone discovered why we were havin
26 matches
Mail list logo
