pg.ddx.io pgsql-admin@postgresql.org mailing list archive
help / color / mirror / Atom feedmissing chunk number 0 for toast value ...
12+ messages / 5 participants
[nested] [flat]
* missing chunk number 0 for toast value ...
@ 2006-05-03 20:02 MIlos Prudek <prudek@bvx.cz>
0 siblings, 1 reply; 12+ messages in thread
From: MIlos Prudek @ 2006-05-03 20:02 UTC (permalink / raw)
To: pgsql-admin
Hello postgres wizards :-)
I have a problem with table info:
select * from info;
ERROR: missing chunk number 0 for toast value 190937
Dumping does not work either:
pg_dump db >db.unl
pg_dump: ERROR: missing chunk number 0 for toast value 190937
pg_dump: lost synchronization with server, resetting connection
pg_dump: SQL command to dump the contents of table "info" failed: PQendcopy()
failed.
pg_dump: Error message from server: pg_dump: The command was: COPY public.info
(idsection, idinfo, txt) TO stdout;
I googled, and using advice in an archived post I run the following command:
select relname from pg_class where oid =
(select reltoastrelid from pg_class where relname = 'info');
which resulted in one row with value pg_toast_61934
and then I ran
reindex table pg_toast.pg_toast_61934;
but it did not help.
What should I do to salvage the table?
--
Milos Prudek
^ permalink raw reply [nested|flat] 12+ messages in thread
* Re: missing chunk number 0 for toast value ...
@ 2006-05-03 20:40 Tom Lane <tgl@sss.pgh.pa.us>
parent: MIlos Prudek <prudek@bvx.cz>
0 siblings, 1 reply; 12+ messages in thread
From: Tom Lane @ 2006-05-03 20:40 UTC (permalink / raw)
To: MIlos Prudek <prudek@bvx.cz>; +Cc: pgsql-admin
MIlos Prudek <prudek@bvx.cz> writes:
> select * from info;
> ERROR: missing chunk number 0 for toast value 190937
I was going to suggest the REINDEX, but no luck :-(
> What should I do to salvage the table?
Find the row containing the busted toast reference, and delete that row
(or just UPDATE it with some new value for the toasted column). You can
home in on it with the usual sorts of search methods --- look in the PG
list archives for previous discussions of locating corrupted rows.
regards, tom lane
^ permalink raw reply [nested|flat] 12+ messages in thread
* Re: missing chunk number 0 for toast value ...
@ 2006-05-05 17:49 MIlos Prudek <prudek@bvx.cz>
parent: Tom Lane <tgl@sss.pgh.pa.us>
0 siblings, 0 replies; 12+ messages in thread
From: MIlos Prudek @ 2006-05-05 17:49 UTC (permalink / raw)
To: Tom Lane <tgl@sss.pgh.pa.us>; +Cc: pgsql-admin
> Find the row containing the busted toast reference, and delete that row
> (or just UPDATE it with some new value for the toasted column). You can
> home in on it with the usual sorts of search methods --- look in the PG
> list archives for previous discussions of locating corrupted rows.
Thanks Tom. I ended up restoring the table from the last dump (created by
pg_dump) up to the point where corruption starts. Not the most surgical
solution but justified for my use case.
--
Milos Prudek
^ permalink raw reply [nested|flat] 12+ messages in thread
* missing chunk number 0 for toast value
@ 2008-09-24 18:32 BJ Taylor <btaylor@propertysolutions.com>
0 siblings, 2 replies; 12+ messages in thread
From: BJ Taylor @ 2008-09-24 18:32 UTC (permalink / raw)
To: pgsql-admin
Our database seems to have been corrupted. It is a heavily used database,
and went several months without any type of vacuuming. When we finally
realized that it wasn't being vacuumed, we started the process, but the
process never successfully completed, and our database has never been the
same since.
The exact error that we receive now is as follows:
postgres@server:~> pg_dumpall -p 5433 > dbmail_dumpall_23092008.sql
*pg_dump: SQL command failed
pg_dump: Error message from server: ERROR: missing chunk number 0 for toast
value 554339
pg_dump: The command was: COPY public.dbmail_messageblks (messageblk_idnr,
physmessage_id, blocksize, is_header, messageblk) TO stdout;
pg_dumpall: pg_dump failed on database "dbmail", exiting*
We have tried using the -d option of the pg_dumpall so we could get a full
dump of the database, and just start over from that, but that fails as
well. We have also tried reindexing the table, but although the reindex
didn't fail, it didn't solve our problem either. Our next option is to do a
full vacuum, but we are reluctant to take our mail server down for that
long, especially when we do not know for sure that it will either succeed or
fix our problem. I have searched the forums, but was unable to find a
solution that we have not already tried. The solutions didn't appear to
help others who had this problem either.
Any suggestions?
Thanks,
BJ
^ permalink raw reply [nested|flat] 12+ messages in thread
* Re: missing chunk number 0 for toast value
@ 2008-09-24 19:16 Scott Whitney <swhitney@journyx.com>
parent: BJ Taylor <btaylor@propertysolutions.com>
1 sibling, 0 replies; 12+ messages in thread
From: Scott Whitney @ 2008-09-24 19:16 UTC (permalink / raw)
To: 'BJ Taylor' <btaylor@propertysolutions.com>; pgsql-admin
I ran into this issue awhile ago. Here's my long internal tech note to my
dev guys on what I did. A bit modified for more genericism:
I'm in the process of migrating our internal db server, and I decided to use
the helpdesk as
my test database. It backed up fine last night. Something went horribly
wrong today, since pg_dump tells me:
> pg_dump: ERROR: missing chunk number 0 for toast value 110439697
> pg_dump: SQL command to dump the contents of table "attachments" failed:
> PQendcopy() failed.
> pg_dump: Error message from server: ERROR: missing chunk number 0 for
toast
> value 110439697
> pg_dump: The command was: COPY public.attachments (id, transactionid,
> parent, messageid, subject, filename, contenttype, contentencoding,
content,
> headers, creator, created) TO stdout;
I reindexed attachments. I reindexed the db. I retoasted the index. Or
reindexed the toast. Or toasted the index. Or something:
rt3=# select reltoastrelid::regclass from pg_class where relname =
'attachments';
reltoastrelid
---------------------------
pg_toast.pg_toast_8507627
(1 row)
rt3=# reindex table pg_toast.pg_toast_8507627;
REINDEX
rt3=# \q
-bash-2.05b$ pg_dump rt3 > /tmp/rt3
pg_dump: ERROR: missing chunk number 0 for toast value 110439697
pg_dump: SQL command to dump the contents of table "attachments" failed:
PQendcopy() failed.
pg_dump: Error message from server: ERROR: missing chunk number 0 for toast
value 110439697
pg_dump: The command was: COPY public.attachments (id, transactionid,
parent, messageid, subject, filename, contenttype, contentencoding, content,
headers, creator, created) TO stdout;
That didn't work. So...I figured I could find out what the bad rec was.
Doing this:
Select * from attachments limit 5000 offset 0
Select * from attachments limit 5000 offset 5000
Select * from attachments limit 5000 offset 10000
Select * from attachments limit 5000 offset 15000
quickly showed me that record 16179 was causing this issue.
So, in order to resolve, this I did this:
pg_dump -s rt3 > /tmp/rt3schema
followed by:
for each in `psql rt3 -c "\d" | awk {'print $3'} | grep -vw attachments`;do
pg_dump rt3 -t $each >> /tmp/rt3data; done
(This second one removes only the table named attachments)
Then I used pg.py to do this:
import pg
olddb=pg.connect('rt3','myolddbserver')
new=pg.connect('rt3','localhost')
first=olddb.query("""select * from attachments limit 16169""").getresult()
last=olddb.query("""select * from attachments limit 100000 offset 16170""")
for eachRec in first + last:
new.query("""insert into attachments values %r""" % (eachRec,))
*** I did have to deal with some quotification issues, but you get the
point.
-----Original Message-----
From: pgsql-admin-owner@postgresql.org
[mailto:pgsql-admin-owner@postgresql.org] On Behalf Of BJ Taylor
Sent: Sep 24, 2008 1:32 PM
To: pgsql-admin@postgresql.org
Subject: [ADMIN] missing chunk number 0 for toast value
Our database seems to have been corrupted. It is a heavily used database,
and went several months without any type of vacuuming. When we finally
realized that it wasn't being vacuumed, we started the process, but the
process never successfully completed, and our database has never been the
same since.
The exact error that we receive now is as follows:
postgres@server:~> pg_dumpall -p 5433 > dbmail_dumpall_23092008.sql
pg_dump: SQL command failed
pg_dump: Error message from server: ERROR: missing chunk number 0 for toast
value 554339
pg_dump: The command was: COPY public.dbmail_messageblks (messageblk_idnr,
physmessage_id, blocksize, is_header, messageblk) TO stdout;
pg_dumpall: pg_dump failed on database "dbmail", exiting
We have tried using the -d option of the pg_dumpall so we could get a full
dump of the database, and just start over from that, but that fails as well.
We have also tried reindexing the table, but although the reindex didn't
fail, it didn't solve our problem either. Our next option is to do a full
vacuum, but we are reluctant to take our mail server down for that long,
especially when we do not know for sure that it will either succeed or fix
our problem. I have searched the forums, but was unable to find a solution
that we have not already tried. The solutions didn't appear to help others
who had this problem either.
Any suggestions?
Thanks,
BJ
^ permalink raw reply [nested|flat] 12+ messages in thread
* Re: missing chunk number 0 for toast value
@ 2008-09-24 20:26 Tom Lane <tgl@sss.pgh.pa.us>
parent: BJ Taylor <btaylor@propertysolutions.com>
1 sibling, 1 reply; 12+ messages in thread
From: Tom Lane @ 2008-09-24 20:26 UTC (permalink / raw)
To: BJ Taylor <btaylor@propertysolutions.com>; +Cc: pgsql-admin
"BJ Taylor" <btaylor@propertysolutions.com> writes:
> Our database seems to have been corrupted. It is a heavily used database,
> and went several months without any type of vacuuming. When we finally
> realized that it wasn't being vacuumed, we started the process, but the
> process never successfully completed, and our database has never been the
> same since.
What PG version is this? Exactly what do you mean by "never
successfully completed"?
regards, tom lane
^ permalink raw reply [nested|flat] 12+ messages in thread
* Re: missing chunk number 0 for toast value
@ 2008-09-24 21:46 BJ Taylor <btaylor@propertysolutions.com>
parent: Tom Lane <tgl@sss.pgh.pa.us>
0 siblings, 1 reply; 12+ messages in thread
From: BJ Taylor @ 2008-09-24 21:46 UTC (permalink / raw)
To: Tom Lane <tgl@sss.pgh.pa.us>; +Cc: pgsql-admin
We are using version 8.3.1. And to be precise, when I started the vacuum
(analyze), I started it as a cron job to run daily around midnight. The
next day I came in and checked on it and it was still running. Not thinking
that it would take more than a full 24 hours to run, I let it be, and the
next day I came in and the server started acting weird. I believe the
vacuum process continued to run, and a second vacuum process was started.
The server became unstable, and refused incoming connections. At which
point, I killed all vacuum processes, and restarted postgresql. I believe
it was somewhere during this process that the database became corrupted. I
am not certain what happens when two vacuum processes run at the same time.
That may have been the problem, or it may not have. Or it may have been
that I killed the vacuum process in the middle of what it was doing. One
way or another, the problem that we have now, is that we are unable to get a
dump of the database for backups, and the database seems less stable than it
was previously (dropping connections, and refusing connections seemingly at
random).
BJ
On Wed, Sep 24, 2008 at 2:26 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> "BJ Taylor" <btaylor@propertysolutions.com> writes:
> > Our database seems to have been corrupted. It is a heavily used
> database,
> > and went several months without any type of vacuuming. When we finally
> > realized that it wasn't being vacuumed, we started the process, but the
> > process never successfully completed, and our database has never been the
> > same since.
>
> What PG version is this? Exactly what do you mean by "never
> successfully completed"?
>
> regards, tom lane
>
^ permalink raw reply [nested|flat] 12+ messages in thread
* Re: missing chunk number 0 for toast value
@ 2008-09-25 13:24 Tom Lane <tgl@sss.pgh.pa.us>
parent: BJ Taylor <btaylor@propertysolutions.com>
0 siblings, 1 reply; 12+ messages in thread
From: Tom Lane @ 2008-09-25 13:24 UTC (permalink / raw)
To: BJ Taylor <btaylor@propertysolutions.com>; +Cc: pgsql-admin
"BJ Taylor" <btaylor@propertysolutions.com> writes:
> We are using version 8.3.1. And to be precise, when I started the vacuum
> (analyze), I started it as a cron job to run daily around midnight. The
> next day I came in and checked on it and it was still running. Not thinking
> that it would take more than a full 24 hours to run, I let it be, and the
> next day I came in and the server started acting weird. I believe the
> vacuum process continued to run, and a second vacuum process was started.
> The server became unstable, and refused incoming connections.
Unstable how? What error did you get on the refused connections? What
was showing up in the postmaster log?
> At which
> point, I killed all vacuum processes, and restarted postgresql.
How did you do that killing exactly?
> I believe
> it was somewhere during this process that the database became corrupted. I
> am not certain what happens when two vacuum processes run at the same time.
Nothing of interest, it's done all the time.
> That may have been the problem, or it may not have. Or it may have been
> that I killed the vacuum process in the middle of what it was doing. One
> way or another, the problem that we have now, is that we are unable to get a
> dump of the database for backups, and the database seems less stable than it
> was previously (dropping connections, and refusing connections seemingly at
> random).
Again, what errors are you getting exactly, and what shows up in the
postmaster log?
regards, tom lane
^ permalink raw reply [nested|flat] 12+ messages in thread
* Re: missing chunk number 0 for toast value
@ 2008-09-25 16:09 BJ Taylor <btaylor@propertysolutions.com>
parent: Tom Lane <tgl@sss.pgh.pa.us>
0 siblings, 2 replies; 12+ messages in thread
From: BJ Taylor @ 2008-09-25 16:09 UTC (permalink / raw)
To: pgsql-admin
Hey Tom,
Here are some recent logs from our system. Unfortunately, I didn't think to
grab the logs at the time I killed those processes, and now they are gone.
I found those processes by using ps, and then I killed them with a simple
kill *processid*. Here are samples of our current log files:
FATAL: the database system is in recovery mode
FATAL: the database system is in recovery mode
LOG: autovacuum launcher started
LOG: database system is ready to accept connections
PANIC: right sibling's left-link doesn't match: block 175337 links to
243096 instead of expected 29675 in index "dbmail_headervalue_3"
STATEMENT: INSERT INTO dbmail_headervalue (headername_id, physmessage_id,
headervalue) VALUES (4,12335778,'from [76.13.13.25] by
n6.bullet.mail.ac4.yahoo.com with NNFMP; 25 Sep 2008 04:01:36 -0000')
LOG: server process (PID 13888) was terminated by signal 6: Aborted
LOG: terminating any other active server processes
WARNING: terminating connection because of crash of another server process
DETAIL: The postmaster has commanded this server process to roll back the
current transaction and exit, because another server process exited
abnormally and possibly corrupted shared memory.
HINT: In a moment you should be able to reconnect to the database and
repeat your command.
WARNING: terminating connection because of crash of another server process
DETAIL: The postmaster has commanded this server process to roll back the
current transaction and exit, because another server process exited
abnormally and possibly corrupted shared memory.
HINT: In a moment you should be able to reconnect to the database and
repeat your command.
WARNING: terminating connection because of crash of another server process
DETAIL: The postmaster has commanded this server process to roll back the
current transaction and exit, because another server process exited
abnormally and possibly corrupted shared memory.
HINT: In a moment you should be able to reconnect to the database and
repeat your command.
WARNING: terminating connection because of crash of another server process
DETAIL: The postmaster has commanded this server process to roll back the
current transaction and exit, because another server process exited
abnormally and possibly corrupted shared memory.
HINT: In a moment you should be able to reconnect to the database and
repeat your command.
WARNING: terminating connection because of crash of another server process
DETAIL: The postmaster has commanded this server process to roll back the
current transaction and exit, because another server process exited
abnormally and possibly corrupted shared memory.
HINT: In a moment you should be able to reconnect to the database and
repeat your command.
FATAL: the database system is in recovery mode
WARNING: terminating connection because of crash of another server process
DETAIL: The postmaster has commanded this server process to roll back the
current transaction and exit, because another server process exited
abnormally and possibly corrupted shared memory.
HINT: In a moment you should be able to reconnect to the database and
repeat your command.
FATAL: the database system is in recovery mode
FATAL: the database system is in recovery mode
FATAL: the database system is in recovery mode
FATAL: the database system is in recovery mode
WARNING: terminating connection because of crash of another server process
DETAIL: The postmaster has commanded this server process to roll back the
current transaction and exit, because another server process exited
abnormally and possibly corrupted shared memory.
HINT: In a moment you should be able to reconnect to the database and
repeat your command.
FATAL: the database system is in recovery mode
FATAL: the database system is in recovery mode
LOG: all server processes terminated; reinitializing
LOG: database system was interrupted; last known up at 2008-09-25 09:12:41
MDT
LOG: database system was not properly shut down; automatic recovery in
progress
FATAL: the database system is in recovery mode
FATAL: the database system is in recovery mode
...
FATAL: the database system is in recovery mode
FATAL: the database system is in recovery mode
LOG: redo starts at 3A/2D0DEA78
LOG: record with zero length at 3A/2D1B8D68
LOG: redo done at 3A/2D1B8D3C
LOG: last completed transaction was at log time 2008-09-25
09:12:45.204162-06
FATAL: the database system is in recovery mode
FATAL: the database system is in recovery mode
...
FATAL: the database system is in recovery mode
FATAL: the database system is in recovery mode
LOG: redo starts at 3A/2D1B8DA8
LOG: unexpected pageaddr 3A/2520A000 in log file 58, segment 45, offset
2138112
LOG: redo done at 3A/2D208660
LOG: last completed transaction was at log time 2008-09-25
09:12:47.971207-06
FATAL: the database system is in recovery mode
FATAL: the database system is in recovery mode
...
LOG: unexpected EOF on client connection
LOG: unexpected EOF on client connection
ERROR: missing chunk number 0 for toast value 554365
STATEMENT: SELECT messageblk, is_header FROM dbmail_messageblks WHERE
physmessage_id = 12111760 ORDER BY messageblk_idnr
LOG: unexpected EOF on client connection
LOG: unexpected EOF on client connection
To be honest, I don't know if all of these logs are relevant or not. I half
way suspect that nagios causes the "unexpected EOF on client connection"
notices, but I can't be certain.
You also asked how it is being unstable. It drops connections seemingly at
random. The error received when a connection is dropped is the following:
WARNING: terminating connection because of crash of another server process
DETAIL: The postmaster has commanded this server process to roll back the
current transaction and exit, because another server process exited
abnormally and possibly corrupted shared memory.
HINT: In a moment you should be able to reconnect to the database and
repeat your command.
Please let me know if there are any other questions I can answer for you.
Thanks,
BJ
On Thu, Sep 25, 2008 at 7:24 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> "BJ Taylor" <btaylor@propertysolutions.com> writes:
> > We are using version 8.3.1. And to be precise, when I started the
> vacuum
> > (analyze), I started it as a cron job to run daily around midnight. The
> > next day I came in and checked on it and it was still running. Not
> thinking
> > that it would take more than a full 24 hours to run, I let it be, and the
> > next day I came in and the server started acting weird. I believe the
> > vacuum process continued to run, and a second vacuum process was started.
> > The server became unstable, and refused incoming connections.
>
> Unstable how? What error did you get on the refused connections? What
> was showing up in the postmaster log?
>
> > At which
> > point, I killed all vacuum processes, and restarted postgresql.
>
> How did you do that killing exactly?
>
> > I believe
> > it was somewhere during this process that the database became corrupted.
> I
> > am not certain what happens when two vacuum processes run at the same
> time.
>
> Nothing of interest, it's done all the time.
>
> > That may have been the problem, or it may not have. Or it may have been
> > that I killed the vacuum process in the middle of what it was doing. One
> > way or another, the problem that we have now, is that we are unable to
> get a
> > dump of the database for backups, and the database seems less stable than
> it
> > was previously (dropping connections, and refusing connections seemingly
> at
> > random).
>
> Again, what errors are you getting exactly, and what shows up in the
> postmaster log?
>
> regards, tom lane
>
> --
> Sent via pgsql-admin mailing list (pgsql-admin@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-admin
>
^ permalink raw reply [nested|flat] 12+ messages in thread
* Re: missing chunk number 0 for toast value
@ 2008-09-25 17:30 Tom Lane <tgl@sss.pgh.pa.us>
parent: BJ Taylor <btaylor@propertysolutions.com>
1 sibling, 0 replies; 12+ messages in thread
From: Tom Lane @ 2008-09-25 17:30 UTC (permalink / raw)
To: BJ Taylor <btaylor@propertysolutions.com>; +Cc: pgsql-admin
"BJ Taylor" <btaylor@propertysolutions.com> writes:
> Here are some recent logs from our system. Unfortunately, I didn't think to
> grab the logs at the time I killed those processes, and now they are gone.
> I found those processes by using ps, and then I killed them with a simple
> kill *processid*. Here are samples of our current log files:
Huh. That would have generated SIGTERM, which should at least mostly be
safe. We did recently fix a couple of problems with cleanup after
SIGTERM but they were both pretty low-probability risks. Anyway,
you've definitely got issues now:
> PANIC: right sibling's left-link doesn't match: block 175337 links to
> 243096 instead of expected 29675 in index "dbmail_headervalue_3"
Try reindexing that index, and any other ones that you see complaints
about.
> You also asked how it is being unstable. It drops connections seemingly at
> random. The error received when a connection is dropped is the following:
> WARNING: terminating connection because of crash of another server process
Well, that's just the fallout from a PANIC in some other session; if you
weren't watching the session that actually crashed, you need to look in
the postmaster log to see what went wrong.
regards, tom lane
^ permalink raw reply [nested|flat] 12+ messages in thread
* Re: missing chunk number 0 for toast value
@ 2008-09-25 19:04 Scott Marlowe <scott.marlowe@gmail.com>
parent: BJ Taylor <btaylor@propertysolutions.com>
1 sibling, 1 reply; 12+ messages in thread
From: Scott Marlowe @ 2008-09-25 19:04 UTC (permalink / raw)
To: BJ Taylor <btaylor@propertysolutions.com>; +Cc: pgsql-admin@postgresql.org, "Tom Lane" <tgl@sss.pgh.pa.us>
On Thu, Sep 25, 2008 at 10:09 AM, BJ Taylor
<btaylor@propertysolutions.com> wrote:
> PANIC: right sibling's left-link doesn't match: block 175337 links to
> 243096 instead of expected 29675 in index "dbmail_headervalue_3"
> STATEMENT: INSERT INTO dbmail_headervalue (headername_id, physmessage_id,
> headervalue) VALUES (4,12335778,'from [76.13.13.25] by
> n6.bullet.mail.ac4.yahoo.com with NNFMP; 25 Sep 2008 04:01:36 -0000')
> LOG: server process (PID 13888) was terminated by signal 6: Aborted
> LOG: terminating any other active server processes
> WARNING: terminating connection because of crash of another server process
Tom, does postgres generate abort signal? Or would this be an external signal?
^ permalink raw reply [nested|flat] 12+ messages in thread
* Re: missing chunk number 0 for toast value
@ 2008-09-25 19:34 Tom Lane <tgl@sss.pgh.pa.us>
parent: Scott Marlowe <scott.marlowe@gmail.com>
0 siblings, 0 replies; 12+ messages in thread
From: Tom Lane @ 2008-09-25 19:34 UTC (permalink / raw)
To: Scott Marlowe <scott.marlowe@gmail.com>; +Cc: BJ Taylor <btaylor@propertysolutions.com>; pgsql-admin
"Scott Marlowe" <scott.marlowe@gmail.com> writes:
> On Thu, Sep 25, 2008 at 10:09 AM, BJ Taylor
> <btaylor@propertysolutions.com> wrote:
>> PANIC: right sibling's left-link doesn't match: block 175337 links to
>> 243096 instead of expected 29675 in index "dbmail_headervalue_3"
>> STATEMENT: INSERT INTO dbmail_headervalue (headername_id, physmessage_id,
>> headervalue) VALUES (4,12335778,'from [76.13.13.25] by
>> n6.bullet.mail.ac4.yahoo.com with NNFMP; 25 Sep 2008 04:01:36 -0000')
>> LOG: server process (PID 13888) was terminated by signal 6: Aborted
>> LOG: terminating any other active server processes
>> WARNING: terminating connection because of crash of another server process
> Tom, does postgres generate abort signal? Or would this be an external signal?
Yeah, we call abort() after reporting a PANIC error, so as to get a core
dump.
regards, tom lane
^ permalink raw reply [nested|flat] 12+ messages in thread
end of thread, other threads:[~2008-09-25 19:34 UTC | newest]
Thread overview: 12+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2006-05-03 20:02 missing chunk number 0 for toast value ... MIlos Prudek <prudek@bvx.cz>
2006-05-03 20:40 ` Tom Lane <tgl@sss.pgh.pa.us>
2006-05-05 17:49 ` MIlos Prudek <prudek@bvx.cz>
2008-09-24 18:32 missing chunk number 0 for toast value BJ Taylor <btaylor@propertysolutions.com>
2008-09-24 19:16 ` Re: missing chunk number 0 for toast value Scott Whitney <swhitney@journyx.com>
2008-09-24 20:26 ` Re: missing chunk number 0 for toast value Tom Lane <tgl@sss.pgh.pa.us>
2008-09-24 21:46 ` Re: missing chunk number 0 for toast value BJ Taylor <btaylor@propertysolutions.com>
2008-09-25 13:24 ` Re: missing chunk number 0 for toast value Tom Lane <tgl@sss.pgh.pa.us>
2008-09-25 16:09 ` Re: missing chunk number 0 for toast value BJ Taylor <btaylor@propertysolutions.com>
2008-09-25 17:30 ` Re: missing chunk number 0 for toast value Tom Lane <tgl@sss.pgh.pa.us>
2008-09-25 19:04 ` Re: missing chunk number 0 for toast value Scott Marlowe <scott.marlowe@gmail.com>
2008-09-25 19:34 ` Re: missing chunk number 0 for toast value Tom Lane <tgl@sss.pgh.pa.us>
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox