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,
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
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
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
"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
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
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
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
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
--
"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
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 ...
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
35 matches
Mail list logo
