BUG #4296: Server crashes by restoring database

"Michal Szelag" <msz@szel.pl> writes:

i have a server crash by retoring database.

I try to retore my database from a custom package with pg_restore and prom a
plain package with psql. In both i have the same problem, psl and pg_restore
outputs:
pg_restore: [archiver (db)] error returned by PQputCopyData: server closed
the connection unexpectedly

You're evidently tripping over some kind of bug, but we can't help you
without a lot more detail than this. Try to identify the exact command
that's crashing (hint: turn on log_statements and watch the postmaster
log). See if you can put together a self-contained script that causes
the crash. That will let us fix the problem, and it might let you find
a workaround to reload your data even in advance of a real fix.

regards, tom lane

Dnia piątek, 11 lipca 2008, Tom Lane napisał:

"Michal Szelag" <msz@szel.pl> writes:

i have a server crash by retoring database.

I try to retore my database from a custom package with pg_restore and
prom a plain package with psql. In both i have the same problem, psl and
pg_restore outputs:
pg_restore: [archiver (db)] error returned by PQputCopyData: server
closed the connection unexpectedly

You're evidently tripping over some kind of bug, but we can't help you
without a lot more detail than this. Try to identify the exact command
that's crashing (hint: turn on log_statements and watch the postmaster
log). See if you can put together a self-contained script that causes
the crash. That will let us fix the problem, and it might let you find
a workaround to reload your data even in advance of a real fix.

regards, tom lane

Hallo,
the crash occurs by this command in my dump:

COPY users_history (users_history_id, users_id, uh_date, uh_php_session_id,
uh_gpsc, uh_ip, uh_browser, uh_referer, uh_url) FROM stdin;

so, i excluded this table from my dump and the same error occurs by this
command:
ALTER TABLE ONLY invoices_lines ADD CONSTRAINT invoices_lines_pkey PRIMARY KEY
(nagid, o, linid);

The plain dump of my database has size of 4GB.

I have divided my dump with head, tail, grep, dd, etc. and i have restored my
database(a have spend a lot of time by this).

Best regerds, Michał Szeląg.
--
==================================
Michał Szeląg
tel.: +48 693 11 37 55

=?iso-8859-2?q?Micha=B3_Szel=B1g?= <msz@szel.pl> writes:

the crash occurs by this command in my dump:

COPY users_history (users_history_id, users_id, uh_date, uh_php_session_id,
uh_gpsc, uh_ip, uh_browser, uh_referer, uh_url) FROM stdin;

so, i excluded this table from my dump and the same error occurs by this
command:
ALTER TABLE ONLY invoices_lines ADD CONSTRAINT invoices_lines_pkey PRIMARY KEY
(nagid, o, linid);

You still haven't given anywhere near enough information to identify the
bug. I wonder though if any of these tables involve non-built-in
datatypes? An out-of-date .so file for an add-on datatype could easily
lead to crashes in these operations.

regards, tom lane

Dnia poniedziałek, 14 lipca 2008, Tom Lane napisał:

=?iso-8859-2?q?Micha=B3_Szel=B1g?= <msz@szel.pl> writes:

the crash occurs by this command in my dump:

COPY users_history (users_history_id, users_id, uh_date,
uh_php_session_id, uh_gpsc, uh_ip, uh_browser, uh_referer, uh_url) FROM
stdin;

so, i excluded this table from my dump and the same error occurs by this
command:
ALTER TABLE ONLY invoices_lines ADD CONSTRAINT invoices_lines_pkey
PRIMARY KEY (nagid, o, linid);

You still haven't given anywhere near enough information to identify the
bug. I wonder though if any of these tables involve non-built-in
datatypes? An out-of-date .so file for an add-on datatype could easily
lead to crashes in these operations.

regards, tom lane

I have composite types in my dump, there are some arrays of them too. There
are no over datatypes.

earlier i had messages by restoring this database like this:

Consider increasing the configuration parameter "checkpoint_segments".
checkpoints are occurring too frequently (17 seconds apart).

So i have increased this parameter and shared memory, but the crash stays.

Best regards, M.Sz.

--
==================================
Michał Szeląg
tel.: +48 693 11 37 55

=?iso-8859-2?q?Micha=B3_Szel=B1g?= <msz@szel.pl> writes:

Dnia poniedzia�ek, 14 lipca 2008, Tom Lane napisa�:

You still haven't given anywhere near enough information to identify the
bug. I wonder though if any of these tables involve non-built-in
datatypes? An out-of-date .so file for an add-on datatype could easily
lead to crashes in these operations.

I have composite types in my dump, there are some arrays of them too. There
are no over datatypes.

We're not going to be able to do much about this bug report unless you
can provide a test case. There's just not enough information here to
even begin looking for a cause.

regards, tom lane