Thread: BUG #4296: Server crashes by restoring database
The following bug has been logged online: Bug reference: 4296 Logged by: Michal Szelag Email address: msz@szel.pl PostgreSQL version: 8.3.3 Operating system: 2.6.23-1-amd64[debian etch] Description: Server crashes by restoring database Details: Hallo, very sory for my bad english: 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 and i have messages in my log file: server process (PID 11351) exited with exit code 255 terminating any other active server processes all server processes terminated; reinitializing my database contains composite types and array composite types. Can you tell me, haw can i restore my database? Best Regerds, M.Sz.
"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
Michał Szeląg <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ł: > Michał Szeląg <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
Michał Szeląg <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