Hi
Is it possible to restore pg db with the same oids
On 12/5/2012 4:40 AM, Branka Stancic wrote:
I have problem.
I want to restore only data in database.
In pgAdmin I was backup only data from old database and now i have
backup file backup.sql.
In terminale I want restore only data in new database and I using
command pg_restore -i -h localhost -
Branka Stancic wrote:
> I using command pg_restore
> get an error: pg_restore: [archiver] input file appears to be a
> text format dump. Please use psql
pg_restore is not used for restoring text files; psql is. If you
want to use pg_restore you should use -Fc when you run pg_dump. At
this point,
Hi,I have problem.I want to restore only data in database.In pgAdmin I was
backup only data from old database and now i have backup file backup.sql.In
terminale I want restore only data in new database and I using command
pg_restore -i -h localhost -p 5432 -U postgres -d payroll --data-only -
ards,
Satheesan K Nair
India
- Original Message -
From: "Magnus Hagander"
To: "Heikki Linnakangas"
Cc: "Satheesan K Nair" ;
Sent: Monday, October 31, 2011 4:57 PM
Subject: Re: [BUGS] pg_restore: [custom archiver] error during file seek:
Invalid argument
On
Nair"
Cc:
Sent: Monday, October 31, 2011 3:25 PM
Subject: Re: [BUGS] pg_restore: [custom archiver] error during file seek:
Invalid argument
On 31.10.2011 07:55, Satheesan K Nair wrote:
We are trying to restore a 3.2GB sized POstgreSql 8.1 Data base. When it
is reaching a particular tabl
ok... let me try the same and check.
Thanks for your valuable support.
- Original Message -
From: "Heikki Linnakangas"
To: "Satheesan K Nair"
Cc:
Sent: Monday, October 31, 2011 4:33 PM
Subject: Re: [BUGS] pg_restore: [custom archiver] error during file see
On Mon, Oct 31, 2011 at 12:03, Heikki Linnakangas
wrote:
> On 31.10.2011 12:12, Satheesan K Nair wrote:
>>
>> Our Operating System is Windows XP.
>>
>> Should we need to do any changes in any kind of configurations in
>> Windows XP or PostgreSql??
>
> According to the commit logs, there was a win3
On 31.10.2011 12:12, Satheesan K Nair wrote:
Our Operating System is Windows XP.
Should we need to do any changes in any kind of configurations in
Windows XP or PostgreSql??
According to the commit logs, there was a win32-related fix to this on
8.2, and some further MinGW-related changes in 8
On 31.10.2011 07:55, Satheesan K Nair wrote:
We are trying to restore a 3.2GB sized POstgreSql 8.1 Data base. When it is reaching a
particular table restoration, giving error as "pg_restore: [custom archiver] error
during file seek: Invalid argument" and exiting the restoration.
Then when we h
Dear Supporter,
We are trying to restore a 3.2GB sized POstgreSql 8.1 Data base. When it is
reaching a particular table restoration, giving error as "pg_restore: [custom
archiver] error during file seek: Invalid argument" and exiting the restoration.
Then when we have googled it, we found that
I wrote:
> Julian Mehnle writes:
>> What would "removing that code entirely" mean?
> I was wondering why it's necessary to parse the entry in the dump file
> at all, rather than just spit it out to PQexec as-is. There's probably
> a reason, but maybe we can find another way to solve whatever the
Alvaro Herrera wrote:
> Note that CCing others is customary but obviously not mandatory.
For the record, CCing posters who haven't explicitly requested it is
frowned upon on the Debian mailing lists , but apparently those have a
lower latency than the Pg ones. :-)
I'll shut up now since this i
Excerpts from Julian Mehnle's message of mié jul 27 13:28:21 -0400 2011:
> Tom Lane wrote:
>
> > Julian Mehnle writes:
> > > I'm subscribed to the pgsql-bugs list, so no need to CC me. :-)
> >
> > cc to people in the thread is the established practice on these lists.
> > It provides a bit more ro
Tom Lane wrote:
> Julian Mehnle writes:
> > I'm subscribed to the pgsql-bugs list, so no need to CC me. :-)
>
> cc to people in the thread is the established practice on these lists.
> It provides a bit more robustness when the lists are busy or slow.
Got it. I'll try to remember that and CC ot
Julian Mehnle writes:
> I'm subscribed to the pgsql-bugs list, so no need to CC me. :-)
cc to people in the thread is the established practice on these lists.
It provides a bit more robustness when the lists are busy or slow.
You can set your subscription so the listserv won't send you an extra
c
I'm subscribed to the pgsql-bugs list, so no need to CC me. :-)
Tom Lane wrote:
> Reproduced here against HEAD. The problem seems to be that
> pg_backup_db.c's _sendSQLLine() contains a mini SQL lexer that is not
> cognizant of standard_conforming_strings.
Oh, right, I forgot to mention I have
Julian Mehnle writes:
> If the comment/description of a database object (table, function, etc.)
> ends in a backslash (which generally works fine otherwise), then
> pg_restore is unable to completely restore a custom-format dump of the
> schema.
Reproduced here against HEAD. The problem seems to
I observe the following issue on PostgreSQL 9.0.4 on at least the
following platforms:
* FreeBSD 6.3 (amd64)
`uname -a`:
FreeBSD 6.3-STABLE FreeBSD 6.3-STABLE #1: Fri May 30 18:11:47
PDT 2008
root@:/data/obj/data/home//symbols/builddir_amd64/usr/src/sys/MESSAGING_GATEWAY.amd64_I
On Thu, Jun 10, 2010 at 9:39 AM, Tom Lane wrote:
> Robert Haas writes:
>> I believe this is the commit:
>
>> http://git.postgresql.org/gitweb?p=postgresql.git;a=commit;h=3a524653d18f29676b91f740634a673b72beb6b5
>
>> It looks like the code was changed, but I don't see any doc updates.
>
> Eh?
> ht
Robert Haas writes:
> I believe this is the commit:
> http://git.postgresql.org/gitweb?p=postgresql.git;a=commit;h=3a524653d18f29676b91f740634a673b72beb6b5
> It looks like the code was changed, but I don't see any doc updates.
Eh?
http://archives.postgresql.org/pgsql-committers/2010-05/msg00191
On Thu, Jun 10, 2010 at 3:58 AM, Russell Smith wrote:
> On 15/05/10 05:15, Alvaro Herrera wrote:
>> Excerpts from Tom Lane's message of vie may 14 13:26:06 -0400 2010:
>>
>>
>>> However, I think -C is a special case because it's quite un-obvious
>>> to the user that it effectively acts as a filter
On 15/05/10 05:15, Alvaro Herrera wrote:
> Excerpts from Tom Lane's message of vie may 14 13:26:06 -0400 2010:
>
>
>> However, I think -C is a special case because it's quite un-obvious
>> to the user that it effectively acts as a filter switch --- in fact a
>> de-filtering switch, because the l
On 15/05/10 03:26, Tom Lane wrote:
> Russell Smith writes:
>
>>> By the operation of other items (-C --data-only) passed with -l, it only
>>> produces to contents that would be restored with the other switches
>>> provided. If that's expect behavior, then the documentation of the
>>> switch is
Excerpts from Tom Lane's message of vie may 14 13:26:06 -0400 2010:
> However, I think -C is a special case because it's quite un-obvious
> to the user that it effectively acts as a filter switch --- in fact a
> de-filtering switch, because the lack of -C is what filters out the
> DATABASE item.
>
Russell Smith writes:
>> By the operation of other items (-C --data-only) passed with -l, it only
>> produces to contents that would be restored with the other switches
>> provided. If that's expect behavior, then the documentation of the
>> switch is incorrect and should read something more like
On 13/05/10 19:26, Russell Smith wrote:
> On 13/05/10 03:39, Tom Lane wrote:
>
>> Russell Smith writes:
>>
>>
>>> pg_restore silently ignores the inclusion of -C when you do use a
>>> restore list.
>>>
>>>
>> It would work as you expect if you use -C when creating the list f
On 13/05/10 03:39, Tom Lane wrote:
> Russell Smith writes:
>
>> pg_restore silently ignores the inclusion of -C when you do use a
>> restore list.
>>
> It would work as you expect if you use -C when creating the list file.
> The reason for this is that -C basically means "don't skip the DA
Russell Smith writes:
> pg_restore silently ignores the inclusion of -C when you do use a
> restore list.
It would work as you expect if you use -C when creating the list file.
The reason for this is that -C basically means "don't skip the DATABASE
entry". When you use -l without -C, you get a l
Hi,
pg_restore silently ignores the inclusion of -C when you do use a
restore list.
postgres$ pg_dump -Fc postgres > postgres.dump
postgres$ pg_restore -C postgres.dump | grep 'CREATE DATABASE'
CREATE DATABASE postgres WITH TEMPLATE = template0 ENCODING = 'UTF8';
## Create a restore list
postgre
"Erik Rijkers" writes:
> I ran into a bug in pg_restore, where it silently omits
> to restore a constraint (here a primary key):
pg_restore's notion of what -t means is very much more restricted than
pg_dump's is. We might change this someday, but don't hold your breath
(ie, it's a missing featu
(linux/Centos 5.2, postgres 84beta1, but also 8.3)
Hello,
I ran into a bug in pg_restore, where it silently omits
to restore a constraint (here a primary key):
(this is 8.4 beta 1, but the same occurs in 8.3)
echo "
drop table if exists public.j;
create table public.j (jnr integer N
On Aug 1, 2006, at 7:24 AM, Jan Cruz wrote:
I am having problem with pg_restore 8.1.4
pg_restore: [custom archiver] out of memory
pg_restore: *** aborted because of error
Is that the only output you get?
What's maintenance_work_mem set to, and how much memory and swap do
you have? Is the ma
On Tue, Aug 01, 2006 at 04:16:29PM +0800, Wang Haiyong wrote:
> Hello, I run pg_restore on windows. I meet a problem. It is ...
>
> pg_restore not work on windows 2000, when dump file size > 4G and dump file
> format is custom.
[...]
> pg_restore: [archiver] file offset in dump file is too large
Below is the result of restoring specific tables from backup made by pgadmin using postgresql 8.1.4 for windows
Note: Same result also applies to linux distribution of postgresql 8.1.4
--
Hello, I run pg_restore on windows. I meet a problem. It
is ...
pg_restore not work on windows 2000, when dump file
size > 4G and dump file format is custom.
Error information:
dir pg_100.dat
2005-12-13 09:27 4,391,630,151
pg_100.dat
D:\Program Files\PostgreSQL\8.1\bin>pg_restore
I am having problem with pg_restore 8.1.4
pg_restore: [custom archiver] out of memorypg_restore: *** aborted because of error
Wang Haiyong <[EMAIL PROTECTED]> writes:
> pg_restore 8.1.0 parameter( -n) not work¡£
This is fixed in 8.1.4.
2006-04-12 18:19 tgl
* src/bin/pg_dump/: pg_backup_archiver.c, pg_restore.c
(REL8_1_STABLE): Fix pg_restore -n option to do what the man page
says it does. The
Hello, I run pg_restore on linux. I meet a problem. It is
...
pg_restore 8.1.0 parameter( -n) not
work。
TEST CASE:
[EMAIL PROTECTED] ~]$ createdb db5CREATE
DATABASE[EMAIL PROTECTED] ~]$ psql db5Welcome to psql 8.1.0, the PostgreSQL
interactive terminal.
Type: \cop
I had similar problems with the tar format. 3 smaller databases worked,
the biggest did not. Switching to -Fc fixed it for me.
Sorry for not reporting this.
Harco
Tom Lane wrote:
Michael Andreasen <[EMAIL PROTECTED]> writes:
pg_dump -Ft $db | bzip2 > $db.dump.tbz
...
pg_restore: [tar arch
Michael Andreasen <[EMAIL PROTECTED]> writes:
> pg_dump -Ft $db | bzip2 > $db.dump.tbz
> ...
> pg_restore: [tar archiver] could not find header for file 3765.dat in
> tar archive
Does it work better if you use -Fc format? There was a similar report
recently, which makes me think the tar-format c
I have a problem restoring our large database. This has only stared
happening since we moved to 8.1.x
We are currently on 8.1.3.
We perform an over night dump of the database as follows;
pg_dump -Ft $db | bzip2 > $db.dump.tbz
This happens fine, without any errors.
On our backup machine also
Stephen Frost <[EMAIL PROTECTED]> writes:
> It seems like pg_restore really should be able to handle COPY errors
> correctly by skipping to the end of the COPY data segment when the
> initial COPY command comes back as an error.
Send a patch ;-)
regards, tom lane
--
Greetings,
pg_restore doesn't handle errors very well. While attempting to
upgraded a database from 8.0 to 8.1 there were some errors creating
some tables because 8.0 had PostGIS installed (along with some tables)
and 8.1 did not. This also meant that attempts to load the tables
which
Using psql 8.1.0 on CentOS 4.2, I am trying to upgrade a 400GB database
from pgsql 7.4.7. I made the dump using pg_dump from 8.1.0. After
crunching for 5 hours, pg_restore reports:
pg_restore: [custom archiver] could not uncompress data: incorrect data
check
the postgresql.log says:
2005-12-06 1
"Brian Hackett" <[EMAIL PROTECTED]> writes:
> From manual examination of the code, it looks like pg_restore will corrupt
> an internal data structure on certain abnormal inputs.
Yeah, I think you are right. Looks easy to fix though: we already are
building a flag array from the input, so just add
>From manual examination of the code, it looks like pg_restore will corrupt
an internal data structure on certain abnormal inputs.
File: postgresql-8.0.2/src/bin/pg_dummp/pg_backup_archiver.c
SortTocFromFile pulls dump IDs out of a file and uses them to sort the list
entries in field toc of archi
Hello all!!
I'm in a trouble restoring a database.
System:
PostgreSQL 8.0
Windows 2000 Professional SP4
when I do pg_dump to backup mydb:
C:\Archivos de programa\PostgreSQL\8.0\bin>pg_dump -U juan --format=c
mydb > back2
Password:
pg_dump: [custom archiver] WARNING: ftell mismatch with expected
Fabien COELHO <[EMAIL PROTECTED]> writes:
> It seems to me that "pg_restore -d base" is broken in CVS head on my linux
> debian box.
Yup. A patch intended to suppress comments actually suppressed *all*
DDL commands from pg_restore :-(. Very sloppy work from Philip and/or
Bruce ...
Hi,
I created a new database in the win32
version of 8.0 beta1 and added some functions.
I then did a pg_dump like so:
C:\Program Files\PostgreSQL\8.0-beta1\bin>pg_dump
--username=postgres --format=c
--file=c:\testdb.bak testdb
the backup is created successfully.
I then try to restore with pg_r
Title: Message
Hi,
I am trying to
restore data from a production server (using Postgresql 7.3.x) to a test server
using the latest release 7.4.1.
This is what I
did:
1) dropdb -U
postgres testdb
2) createdb -U
postgres testdb
3) pg_restore -U
postgres -O -d testdb data.tar
It throws this
Is there a bug in pg_restore 7.2.2 (didn't test in others) related
to pg_restore? This take more than 14 hours to be done in a
Database with 1.5 GB:
$pg_restore -a -d DB2 -Fc -o -v DB1.dump
why?
TIA,
Ricardo.
---(end of broadcast)---
TIP 6: Have
Mike Finn <[EMAIL PROTECTED]> writes:
> While upgrading to 7.1.3 (from 7.1.2) I discovered that pg_restore was not
> honouring the --data-only command line option.
Looks like this is already fixed in current sources. Thanks for the
report though!
regards, tom lane
While upgrading to 7.1.3 (from 7.1.2) I discovered that pg_restore was not
honouring the --data-only command line option. Can't actually remember if
it worked in 7.1.2 or not.
Particulars:
postgresql-7.1.3.tar.gz
compiled under Linux mandrake 7.2
command used from a shell script
pg_restore
54 matches
Mail list logo
