Re: [ADMIN] Creating role using batch file in windows

2010-10-26 Thread Thomas Kellerer
Lukasz Brodziak, 26.10.2010 08:58: The problem with a batch file is that you will need to provide the password for the superuser in clear text - which is probably not something you will want to do. But if that isn't a problem (and you actually know the superuser password of your client) then the

[ADMIN] large database: problems with pg_dump and pg_restore

2010-10-26 Thread Martin Povolny
Hallo, I have some quite grave problems with dumping and restoring large databases (>4GB of dump). I had 5 databases, 4 dumped ok, the 5th, the largest failed dumping: I was unable to make a dump in the default 'tar' format. I got this message: pg_dump: [tar archiver] archive member too large

Re: [ADMIN] pg_dump/restore problems

2010-10-26 Thread Bob Lunney
Glen, Did you drop the indexes prior to the restore?  If not, try doing so and recreating the indexes afterwards.  That will also speed up the data load. Bob Lunney --- On Mon, 2/15/10, Glen Brown wrote: From: Glen Brown Subject: [ADMIN] pg_dump/restore problems To: pgsql-admin@postgresql.org

[ADMIN] postgres 8.4.5 jdbc is 8.4-701.jdbc3

2010-10-26 Thread Maria L. Wilson
hopefully quick question - is this jdbc driver (postgres-8.4-701.jdbc3.jar ) compatible with postgres 8.4.5? just curious if we need to rebundle a new jar file... we are upgrading postgres from 8.4.1 to 8.4.5 thanks, Maria Wilson NASA Langley Research Center Hampton, Virginia 23681 -- S

Re: [ADMIN] postgres 8.4.5 jdbc is 8.4-701.jdbc3

2010-10-26 Thread Vibhor Kumar
> > is this jdbc driver (postgres-8.4-701.jdbc3.jar ) compatible with postgres > 8.4.5? > Yes it is compatible. > just curious if we need to rebundle a new jar file... we are upgrading > postgres from 8.4.1 to 8.4.5 > > If you are using jdbc driver compatible with 8.4.1 then, no need to.

Re: [ADMIN] large database: problems with pg_dump and pg_restore

2010-10-26 Thread lst_hoe02
Zitat von Martin Povolny : Hallo, I have some quite grave problems with dumping and restoring large databases (>4GB of dump). I had 5 databases, 4 dumped ok, the 5th, the largest failed dumping: I was unable to make a dump in the default 'tar' format. I got this message: pg_dump: [tar a

Re: [ADMIN] large database: problems with pg_dump and pg_restore

2010-10-26 Thread Samuel Stearns
You can also try piping the dump through gzip and then restoring using cat: pg_dumpall | gzip > db.out-`date +\%Y\%m\%d\%H`.gz cat db.out-`date +\%Y\%m\%d\%H`.gz | gunzip | psql template1 Sam From: pgsql-admin-ow...@postgresql.org [mailto:pgsql-admin-ow...@postgresql.org] On Behalf Of Martin

Re: [ADMIN] large database: problems with pg_dump and pg_restore

2010-10-26 Thread Jehan-Guillaume (ioguix) de Rorthais
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Or even compress AND split it ! pg_dump -Fc dbname | split -b 1G - dump_dbname and restore: cat dump_dbname* | pg_restore -d dbname or cat dump_dbname* | pg_restore | psql dbname Le 26/10/2010 23:51, Samuel Stearns a écrit : > You can also try

Re: [ADMIN] large database: problems with pg_dump and pg_restore

2010-10-26 Thread Tom Lane
=?utf-8?Q?Martin_Povolny?= writes: > I had 5 databases, 4 dumped ok, the 5th, the largest failed dumping: I was > unable to > make a dump in the default 'tar' format. I got this message: > pg_dump: [tar archiver] archive member too large for tar format This is expected: tar format has a document

Re: [ADMIN] large database: problems with pg_dump and pg_restore

2010-10-26 Thread mark
A long time ago, (8.1.11 IIRC) We got much better speed not using the compression flag with pg_dump instead piping to gzip (or better yet something like pbzip2 or pigz, but I haven't used them). I think there was a thread about this that had a test case and numbers. IIRC it's because you