Thread: unable to dump database, toast errors
Greetings, Apologies if this comes through twice. I'm running postgresql-7.2.1 on Redhat-7.2, and when attempting to perform a dump with the command: pg_dump -Ft -b -o DB_NAME > /tmp/db.tar it chugs away for a few minutes, and then dies with the following error: pg_dump: dumping out the contents of table artifact_file pg_dump: ERROR: unexpected chunk number 0 (expected 1) for toast value 7685119 pg_dump: lost synchronization with server, resetting connection pg_dump: SQL command to dump the contents of table "artifact_file" failed: PQendcopy() failed. pg_dump: Error message from server: pg_dump: The command was: COPY "artifact_file" WITH OIDS TO stdout; pg_dump: *** aborted because of error I've tried running vacuumdb as follows: vacuumdb -z -v -a -f and its come up clean every time, so i'm really at a loss on how to resolve this. If it matters, the artifact_file table has 782 rows, and is comprised of text and integer datatype columns. Any suggestions would be greatly appreciated. thanks!
Thanks for your reply. Can pgfsck run on a live database, or does it need to be shutdown first? somewhat related, i just scanned through the output from the vacuumdb that i ran, and I found an error related to the artifact_file table: NOTICE: Index pg_toast_302323_idx: NUMBER OF INDEX' TUPLES (86316) IS NOT THE SAME AS HEAP' (86292). Recreate the index. So, i took down the DB, started it in standalone, and ran: reindex INDEX pg_toast_302323_idx but according to the REINDEX dox, i should see a 'REINDEX' if all is well, and i never do, i'm just dumped back to another backend> prompt. Any ideas? On 04/02/03 20:52, Martijn van Oosterhout wrote: > Just for the hell of it, have you tried: > > http://svana.org/kleptog/pgsql/pgfsck.html > > It may help. Let me know if it does. > > Thanks, > > On Wed, Apr 02, 2003 at 08:46:26PM -0800, Lonni Friedman wrote: >> Greetings, >> Apologies if this comes through twice. >> >> I'm running postgresql-7.2.1 on Redhat-7.2, and when attempting to >> perform a dump with the command: >> pg_dump -Ft -b -o DB_NAME > /tmp/db.tar >> >> it chugs away for a few minutes, and then dies with the following error: >> >> pg_dump: dumping out the contents of table artifact_file >> pg_dump: ERROR: unexpected chunk number 0 (expected 1) for toast value >> 7685119 >> pg_dump: lost synchronization with server, resetting connection >> pg_dump: SQL command to dump the contents of table "artifact_file" >> failed: PQendcopy() failed. >> pg_dump: Error message from server: pg_dump: The command was: COPY >> "artifact_file" WITH OIDS TO stdout; >> pg_dump: *** aborted because of error >> >> I've tried running vacuumdb as follows: >> vacuumdb -z -v -a -f >> >> and its come up clean every time, so i'm really at a loss on how to >> resolve this. If it matters, the artifact_file table has 782 rows, and >> is comprised of text and integer datatype columns. >> >> Any suggestions would be greatly appreciated. thanks! >> >> >> ---------------------------(end of broadcast)--------------------------- >> TIP 2: you can get off all lists at once with the unregister command >> (send "unregister YourEmailAddressHere" to majordomo@postgresql.org) >
On Wed, Apr 02, 2003 at 09:02:48PM -0800, Lonni Friedman wrote: > Thanks for your reply. Can pgfsck run on a live database, or does it > need to be shutdown first? While you could in theory run it on a live database I wouldn't recommend it given it can't get a consitant snapshot. But if you're just scanning for problems it should be fine. It's a read-only program, it never actually writes to the postgres files. > NOTICE: Index pg_toast_302323_idx: NUMBER OF INDEX' TUPLES (86316) IS > NOT THE SAME AS HEAP' (86292). > Recreate the index. > > So, i took down the DB, started it in standalone, and ran: > reindex INDEX pg_toast_302323_idx > > but according to the REINDEX dox, i should see a 'REINDEX' if all is > well, and i never do, i'm just dumped back to another backend> prompt. > Any ideas? No idea here sorry... -- Martijn van Oosterhout <kleptog@svana.org> http://svana.org/kleptog/ > "the West won the world not by the superiority of its ideas or values or > religion but rather by its superiority in applying organized violence. > Westerners often forget this fact, non-Westerners never do." > - Samuel P. Huntington
Attachment
Lonni Friedman <lfriedman@vasoftware.com> writes:
> So, i took down the DB, started it in standalone, and ran:
> reindex INDEX pg_toast_302323_idx
For a user table you didn't really need to take down the DB.
> but according to the REINDEX dox, i should see a 'REINDEX' if all is
> well, and i never do, i'm just dumped back to another backend> prompt.
That is a user-interface detail that is correct when running psql,
but I don't think a standalone backend bothers with such fine points.
If it didn't spit up an error message then it was happy.
The real question is did pg_dump get any better after you did this?
regards, tom lane
so tom, do you ever sleep? :-) I know you're in Japan, but you're always replying whenever I'm awake! Tom Lane wrote: > > Lonni Friedman <lfriedman@vasoftware.com> writes: > > So, i took down the DB, started it in standalone, and ran: > > reindex INDEX pg_toast_302323_idx > > For a user table you didn't really need to take down the DB. > > > but according to the REINDEX dox, i should see a 'REINDEX' if all is > > well, and i never do, i'm just dumped back to another backend> prompt. > > That is a user-interface detail that is correct when running psql, > but I don't think a standalone backend bothers with such fine points. > If it didn't spit up an error message then it was happy. > > The real question is did pg_dump get any better after you did this? > > regards, tom lane > > ---------------------------(end of broadcast)--------------------------- > TIP 6: Have you searched our list archives? > > http://archives.postgresql.org
Dennis Gearon wrote: so tom, do you ever sleep? :-) I know you're in Japan, but you're always replying whenever I'm awake! Are you really in Japan Tom? http://developer.postgresql.org/ has you as being in Pittsburgh ... Jc
Jean-Christian Imbeault wrote: > > Dennis Gearon wrote: > so tom, do you ever sleep? :-) I know you're in Japan, but you're always > replying whenever I'm awake! > > Are you really in Japan Tom? If he would be, I would expect Tom to send with another timezone than -0500. Someone else (me included) might forget to adjust that. Tom certainly not ;-) Jan -- #======================================================================# # It's easier to get forgiveness for being wrong than for being right. # # Let's break this rule - forgive me. # #================================================== JanWieck@Yahoo.com #
On Thu, 3 Apr 2003, Tom Lane wrote: > Lonni Friedman <lfriedman@vasoftware.com> writes: > > So, i took down the DB, started it in standalone, and ran: > > reindex INDEX pg_toast_302323_idx > > For a user table you didn't really need to take down the DB. attempting to drop pg_toast_302323_idx failed with an error that it was a system index. > > but according to the REINDEX dox, i should see a 'REINDEX' if all is > > well, and i never do, i'm just dumped back to another backend> prompt. > > That is a user-interface detail that is correct when running psql, > but I don't think a standalone backend bothers with such fine points. > If it didn't spit up an error message then it was happy. > > The real question is did pg_dump get any better after you did this? unfortunately, no.
Jean-Christian Imbeault <jc@mega-bucks.co.jp> writes:
> Are you really in Japan Tom?
No...
regards, tom lane
Lonni J Friedman <lfriedman@vasoftware.com> writes:
>> The real question is did pg_dump get any better after you did this?
> unfortunately, no.
Oh well. Have you checked that the reportedly-broken index is in fact
the index for the TOAST table associated with the artifact_file table?
(artifact_file's pg_class row will have the OID of its toast table in
reltoastrelid, and then the reltoastidxid field of the toast table's
row is the OID of its index.) It could be that you've got more than
one problem :-(
If you've actually lost a chunk from a toast value, as seems probable,
I can't think of much to do except manually insert a substitute chunk.
It would run something like
insert into pg_toast_302323 values (7685119, 0, '');
When you dump you will find whichever field value had used that toast
chunk will be corrupted, but at least you'll be able to extract the rest
of the table.
I am somewhat curious as to what happened to the missing chunk, but
I dunno how much effort you want to spend on investigation. A minimum
bit of prudence would be to update this installation to 7.2.4; we don't
make dot-releases just for amusement.
regards, tom lane
On Thu, 3 Apr 2003, Tom Lane wrote:
> Lonni J Friedman <lfriedman@vasoftware.com> writes:
> >> The real question is did pg_dump get any better after you did this?
>
> > unfortunately, no.
thanks for your reply.
> Oh well. Have you checked that the reportedly-broken index is in fact
> the index for the TOAST table associated with the artifact_file table?
> (artifact_file's pg_class row will have the OID of its toast table in
> reltoastrelid, and then the reltoastidxid field of the toast table's
> row is the OID of its index.) It could be that you've got more than
> one problem :-(
i'm not sure that i'm following you 100% here. I'm able to dig this up:
# select * from pg_class where relname='artifact_file';
relname | reltype | relowner | relam | relfilenode | relpages |
reltuples | reltoastrelid | reltoastidxid | relhasindex | relisshared |
relkind | relnatts | relchecks | reltriggers | relukeys | relfkeys |
relrefs | relhasoids | relhaspkey | relhasrules | relhassubclass | relacl
---------------+---------+----------+-------+-------------+----------+-----------+---------------+---------------+-------------+-------------+---------+----------+-----------+-------------+----------+----------+---------+------------+------------+-------------+----------------+--------
artifact_file | 302324 | 100 | 0 | 302323 | 20 |
786 | 302325 | 0 | t | f | r
| 9 | 0 | 0 | 0 | 0 | 0 | t
| t | f | f |
so, am i off base?
> If you've actually lost a chunk from a toast value, as seems probable,
> I can't think of much to do except manually insert a substitute chunk.
> It would run something like
>
> insert into pg_toast_302323 values (7685119, 0, '');
oddly on today's dump attempt, it fails with the following:
pg_dump: ERROR: missing chunk number 1 for toast value 7685119
so i tried:
insert into pg_toast_302323 values (7685119, 1, '');
but that fails:
ERROR: You can't change toast relation pg_toast_302323
> I am somewhat curious as to what happened to the missing chunk, but
> I dunno how much effort you want to spend on investigation. A minimum
> bit of prudence would be to update this installation to 7.2.4; we don't
> make dot-releases just for amusement.
yea, i know. unfortunately, this is a customer's server, and its been an
uphill battle to get them to do any sane maintanence.
thanks for your help,
Lonni
Lonni J Friedman <lfriedman@vasoftware.com> writes:
>> Oh well. Have you checked that the reportedly-broken index is in fact
>> the index for the TOAST table associated with the artifact_file table?
> i'm not sure that i'm following you 100% here. I'm able to dig this up:
Yeah, it looks like 302323 is the OID of artifact_file, so those are the
right TOAST tables for it.
> so i tried:
> insert into pg_toast_302323 values (7685119, 1, '');
> but that fails:
> ERROR: You can't change toast relation pg_toast_302323
Ooops, I was thinking that you could bypass that check as superuser,
but evidently not.
You're probably going to have to do this the hard way: figure out by
elimination which field(s) of which row(s) reference the broken toast
entries, and reset those fields to null (or some valid value, anyway).
It disturbs me quite a bit that the problem seems to be moving around.
That suggests you've got ongoing corruption. Might be a good idea to
run disk and memory diagnostics to find out if there are hardware
problems.
regards, tom lane
On Thu, 3 Apr 2003, Tom Lane wrote: > Lonni J Friedman <lfriedman@vasoftware.com> writes: > > so i tried: > > insert into pg_toast_302323 values (7685119, 1, ''); > > but that fails: > > ERROR: You can't change toast relation pg_toast_302323 > > Ooops, I was thinking that you could bypass that check as superuser, > but evidently not. > > You're probably going to have to do this the hard way: figure out by > elimination which field(s) of which row(s) reference the broken toast > entries, and reset those fields to null (or some valid value, anyway). Do you mean the fields/rows in pg_toast_302323 or artifact_file ? How would i determine which ones reference broken toast entries? Sorry if this is obvious. > It disturbs me quite a bit that the problem seems to be moving around. > That suggests you've got ongoing corruption. Might be a good idea to > run disk and memory diagnostics to find out if there are hardware > problems. yea, this occured to me as well. the DB in question is actually running on a customer's server, so i'd have to convince them to run a manual fsck. I want to make it clear that i greatly appreciate your help on this. i also work with Oracle databases, and pay for a support contract with Oracle, and they have never been as helpful, curteous or prompt in their replies as you have. -Lonni
Lonni J Friedman <lfriedman@vasoftware.com> writes:
> Do you mean the fields/rows in pg_toast_302323 or artifact_file ?
The ones in artifact_file.
> How
> would i determine which ones reference broken toast entries?
If you get the toast error when you try to read the field's value, then
it's broken ...
You may find yourself doing things like "select * from artifact_file
limit N" to try to narrow down which rows contain broken values. If so,
keep in mind that (in 7.2) LIMIT will read one more row than it returns;
so if you can select N rows but not N+1 rows, the problem is actually in
row N+2.
regards, tom lane
On Thu, 3 Apr 2003, Tom Lane wrote: > Lonni J Friedman <lfriedman@vasoftware.com> writes: > > Do you mean the fields/rows in pg_toast_302323 or artifact_file ? > > The ones in artifact_file. > > > How > > would i determine which ones reference broken toast entries? > > If you get the toast error when you try to read the field's value, then > it's broken ... > > You may find yourself doing things like "select * from artifact_file > limit N" to try to narrow down which rows contain broken values. If so, > keep in mind that (in 7.2) LIMIT will read one more row than it returns; > so if you can select N rows but not N+1 rows, the problem is actually in > row N+2. ok, i've got 786 rows to play with, joy. once i find a broken row/field, how do I map that back to pg_toast_302323? thanks.
Lonni J Friedman <lfriedman@vasoftware.com> writes:
> ok, i've got 786 rows to play with, joy. once i find a broken row/field,
> how do I map that back to pg_toast_302323?
Well, it'll tell you which chunk_id it's having a problem with; you
could then look into the toast table to see what the available data is.
(Although the odds are good that the data will have been compressed, so
you won't be able to tell much :-()
As far as recovering, just set the broken field to a new value.
Fortunately the old-value-deletion code is not picky about whether it
finds all the chunks that should be there.
regards, tom lane
On Thu, 3 Apr 2003, Tom Lane wrote: > Lonni J Friedman <lfriedman@vasoftware.com> writes: > > ok, i've got 786 rows to play with, joy. once i find a broken row/field, > > how do I map that back to pg_toast_302323? > > Well, it'll tell you which chunk_id it's having a problem with; you > could then look into the toast table to see what the available data is. > (Although the odds are good that the data will have been compressed, so > you won't be able to tell much :-() hrmmm...i'm not sure that the results i'm getting are matching up with your description of what should occur. This query: select * from artifact_file LIMIT 1 OFFSET 31; consistantly results in psql seg faulting. If I reduce or increase the OFFSET then the query succeeds. So, i was assuming that row 34 (since you said its N+2) has bad data. BUt from what you're saying it sounds like i should be seeing a toast error as an indication of the bad data, and that isn't happening (at least not in the first 60 rows that i've selected so far). Am i missing something obviously boneheaded here? thanks!
Lonni J Friedman <lfriedman@vasoftware.com> writes:
> hrmmm...i'm not sure that the results i'm getting are matching up with
> your description of what should occur. This query:
> select * from artifact_file LIMIT 1 OFFSET 31;
> consistantly results in psql seg faulting. If I reduce or increase the
> OFFSET then the query succeeds.
[ thinks about it... ] Okay, I was being careless about considering
exactly when the value of the item would be accessed. In the above
example, it would seem that row 32 is corrupted in a way that's not
manifested unless we actually attempt to print individual field values;
the bad row can be pulled from the file and fed through the limit/offset
filter without noticing it's bad.
Exactly which field(s) of the bad row can you not select? I would
imagine that simple columns like integers couldn't cause a core dump.
Do the fields that are readable look plausible, or have they been
trashed too?
> But from what you're saying it sounds like i
> should be seeing a toast error as an indication of the bad data, and that
> isn't happening (at least not in the first 60 rows that i've selected so
> far).
It'd seem that this particular row is corrupted in a way that makes it
dump core before it gets to the TOAST table. Or it could be that the
main table row is fine and the problem is corruption in the TOAST data.
The toast errors you reported before are presumably coming from other
rows that have been damaged in different ways.
It'd be useful to get a stack trace out of the core dump, if you have
the tools to do that on the client's machine.
regards, tom lane
On 04/03/03 14:01, Tom Lane wrote:
> Lonni J Friedman <lfriedman@vasoftware.com> writes:
>> hrmmm...i'm not sure that the results i'm getting are matching up with
>> your description of what should occur. This query:
>> select * from artifact_file LIMIT 1 OFFSET 31;
>> consistantly results in psql seg faulting. If I reduce or increase the
>> OFFSET then the query succeeds.
>
> Exactly which field(s) of the bad row can you not select? I would
> imagine that simple columns like integers couldn't cause a core dump.
> Do the fields that are readable look plausible, or have they been
> trashed too?
to better illustrate what i'm talking about:
# \d artifact_file
Table "artifact_file"
Column | Type | Modifiers
--------------+---------+--------------------------------------------------------
id | integer | not null default
nextval('artifact_file_id_seq'::text)
artifact_id | integer | not null
description | text |
bin_data | text |
filename | text | not null
filesize | integer | not null
filetype | text | not null
adddate | integer | not null default '0'
submitted_by | integer | not null
Primary key: artifact_file_pkey
i'm able to run this without any problems:
select
id,artifact_id,description,filename,filesize,filetype,adddate,submitted_by
from artifact_file LIMIT 1 OFFSET 31;
however, if i attempt to select just bin_data (which holds a 6MB M$-Word
doc) it attempts to dump it to screen for a few hundred lines, and then
segfaults.
>> But from what you're saying it sounds like i
>> should be seeing a toast error as an indication of the bad data, and that
>> isn't happening (at least not in the first 60 rows that i've selected so
>> far).
>
> It'd seem that this particular row is corrupted in a way that makes it
> dump core before it gets to the TOAST table. Or it could be that the
> main table row is fine and the problem is corruption in the TOAST data.
at least in the above example it looks to me like its not the toast table.
> The toast errors you reported before are presumably coming from other
> rows that have been damaged in different ways.
i'll start searching for the next bad row, and see what turns up.
> It'd be useful to get a stack trace out of the core dump, if you have
> the tools to do that on the client's machine.
i'm honestly not sure how to do this. the segfault is not producing a
core file that i can find. perhaps i'd need to tinker with ulimit?
even if i managed to get a core dump out of it, i don't really know how
to get a stack trace from it, so i'd need some guidance on that too.
thanks for your continued assistance.
-Lonni
Lonni Friedman <lfriedman@vasoftware.com> writes:
> however, if i attempt to select just bin_data (which holds a 6MB M$-Word
> doc) it attempts to dump it to screen for a few hundred lines, and then
> segfaults.
Wait a second. Which side is segfaulting here? I've been assuming that
you were talking about a backend segfault, but maybe I misunderstood
completely. If it's psql dumping core then we have quite a different
issue.
> i'm honestly not sure how to do this. the segfault is not producing a
> core file that i can find. perhaps i'd need to tinker with ulimit?
Probably. "ulimit -c 0" is a common default these days. Try "ulimit -c
unlimited" before starting the postmaster (resp. psql).
regards, tom lane
On 04/03/03 20:21, Tom Lane wrote: > Lonni Friedman <lfriedman@vasoftware.com> writes: >> however, if i attempt to select just bin_data (which holds a 6MB M$-Word >> doc) it attempts to dump it to screen for a few hundred lines, and then >> segfaults. > > Wait a second. Which side is segfaulting here? I've been assuming that > you were talking about a backend segfault, but maybe I misunderstood > completely. If it's psql dumping core then we have quite a different > issue. its psql, not the backend. >> i'm honestly not sure how to do this. the segfault is not producing a >> core file that i can find. perhaps i'd need to tinker with ulimit? > > Probably. "ulimit -c 0" is a common default these days. Try "ulimit -c > unlimited" before starting the postmaster (resp. psql). ok, is this even neccesary if the problem with the segfault is psql, and not the backend?
Lonni Friedman <lfriedman@vasoftware.com> writes:
>> Probably. "ulimit -c 0" is a common default these days. Try "ulimit -c
>> unlimited" before starting the postmaster (resp. psql).
> ok, is this even neccesary if the problem with the segfault is psql, and
> not the backend?
Yes, even more so, because I can't see any reason for psql to dump core
part way through showing a large result.
regards, tom lane
On 04/03/03 20:32, Tom Lane wrote: > Lonni Friedman <lfriedman@vasoftware.com> writes: >>> Probably. "ulimit -c 0" is a common default these days. Try "ulimit -c >>> unlimited" before starting the postmaster (resp. psql). > >> ok, is this even neccesary if the problem with the segfault is psql, and >> not the backend? > > Yes, even more so, because I can't see any reason for psql to dump core > part way through showing a large result. ok, i got psql to dump core (30M in size). What do I need to do to generate a stack trace?
Lonni Friedman <lfriedman@vasoftware.com> writes:
> ok, i got psql to dump core (30M in size). What do I need to do to
> generate a stack trace?
$ gdb /path/to/psql core
gdb> bt
gdb> quit
If you just get numbers then you need to rebuild with debug symbols
enabled (configure --enable-debug) and try again.
regards, tom lane
On Thu, 3 Apr 2003, Tom Lane wrote: > Lonni Friedman <lfriedman@vasoftware.com> writes: > > ok, i got psql to dump core (30M in size). What do I need to do to > > generate a stack trace? > > $ gdb /path/to/psql core > gdb> bt > gdb> quit > > If you just get numbers then you need to rebuild with debug symbols > enabled (configure --enable-debug) and try again. this looks interesting.... # gdb /usr/bin/psql core GNU gdb Red Hat Linux 7.x (5.0rh-15) (MI_OUT) This GDB was configured as "i386-redhat-linux"... Core was generated by `psql sfee'. Program terminated with signal 11, Segmentation fault. Reading symbols from /usr/lib/libpq.so.2...done. Loaded symbols for /usr/lib/libpq.so.2 Reading symbols from /lib/libpam.so.0...done. Reading symbols from /lib/libssl.so.2...done. Loaded symbols for /lib/libssl.so.2 Reading symbols from /lib/libcrypto.so.2...done. Loaded symbols for /lib/libcrypto.so.2 Reading symbols from /usr/kerberos/lib/libkrb5.so.3...done. Loaded symbols for /usr/kerberos/lib/libkrb5.so.3 Reading symbols from /usr/kerberos/lib/libk5crypto.so.3...done. Loaded symbols for /usr/kerberos/lib/libk5crypto.so.3 Reading symbols from /usr/kerberos/lib/libcom_err.so.3...done. Loaded symbols for /usr/kerberos/lib/libcom_err.so.3 Reading symbols from /usr/lib/libz.so.1...done. Loaded symbols for /usr/lib/libz.so.1 Reading symbols from /lib/libcrypt.so.1...done. Loaded symbols for /lib/libcrypt.so.1 Reading symbols from /lib/libresolv.so.2...done. Loaded symbols for /lib/libresolv.so.2 Reading symbols from /lib/libnsl.so.1...done. Loaded symbols for /lib/libnsl.so.1 Reading symbols from /lib/libdl.so.2...done. Loaded symbols for /lib/libdl.so.2 Reading symbols from /lib/i686/libm.so.6...done. Loaded symbols for /lib/i686/libm.so.6 Reading symbols from /usr/lib/libreadline.so.4...done. Loaded symbols for /usr/lib/libreadline.so.4 Reading symbols from /lib/libtermcap.so.2...done. Loaded symbols for /lib/libtermcap.so.2 Reading symbols from /lib/i686/libc.so.6...done. Loaded symbols for /lib/i686/libc.so.6 Reading symbols from /lib/ld-linux.so.2...done. Loaded symbols for /lib/ld-linux.so.2 Reading symbols from /lib/libnss_compat.so.2...done. Loaded symbols for /lib/libnss_compat.so.2 #0 0x402a1771 in _IO_vfprintf (s=0x4037e180, format=0x8060979 "%-*s%s%-*s", ap=0xbffff90c) at vfprintf.c:1524 1524 vfprintf.c: No such file or directory. in vfprintf.c (gdb) bt #0 0x402a1771 in _IO_vfprintf (s=0x4037e180, format=0x8060979 "%-*s%s%-*s", ap=0xbffff90c) at vfprintf.c:1524 #1 0x402a9ce7 in fprintf (stream=0x4037e180, format=0x8060979 "%-*s%s%-*s") at fprintf.c:32 #2 0x08053464 in print_aligned_text () at eval.c:41 #3 0x080549f0 in printTable () at eval.c:41 #4 0x08054dc7 in printQuery () at eval.c:41 #5 0x0804e089 in SendQuery () at eval.c:41 #6 0x0804fd3f in MainLoop () at eval.c:41 #7 0x08051226 in main () at eval.c:41 #8 0x40266507 in __libc_start_main (main=0x8050b20 <main>, argc=2, ubp_av=0xbffffba4, init=0x8049d70 <_init>, fini=0x8059c80 <_fini>, rtld_fini=0x4000dc14 <_dl_fini>, stack_end=0xbffffb9c) at ../sysdeps/generic/libc-start.c:129 I hope tha this means significantly more to you, than it does to me. Not sure if it matters, but this server is running the (semi) official RPMs from postgresql.org: postgresql-7.2.1-2PGDG
Lonni J Friedman <lfriedman@vasoftware.com> writes:
> I hope tha this means significantly more to you, than it does to me.
It's not real useful :-(. Can you rebuild with debug symbols enabled
and try again?
Also, are you using any nondefault options for formatting psql's output?
regards, tom lane
On Fri, 4 Apr 2003, Tom Lane wrote: > Lonni J Friedman <lfriedman@vasoftware.com> writes: > > I hope tha this means significantly more to you, than it does to me. > > It's not real useful :-(. Can you rebuild with debug symbols enabled > and try again? ok, here goes: (gdb) bt #0 0x4013b771 in _IO_vfprintf (s=0x40218180, format=0x805e2d9 "%-*s%s%-*s", ap=0xbffff81c) at vfprintf.c:1524 #1 0x40143ce7 in fprintf (stream=0x40218180, format=0x805e2d9 "%-*s%s%-*s") at fprintf.c:32 #2 0x080521ea in print_aligned_text (title=0x0, headers=0x8062ff0, cells=0x8063000, footers=0x8063010, opt_align=0x8063088 "l", opt_barebones=0 '\000', opt_border=1, fout=0x40218180) at print.c:329 #3 0x08053522 in printTable (title=0x0, headers=0x8062ff0, cells=0x8063000, footers=0x8063010, align=0x8063088 "l", opt=0x8062b30, fout=0x40218180) at print.c:1123 #4 0x08053888 in printQuery (result=0x80705e0, opt=0x8062b30, fout=0x40218180) at print.c:1257 #5 0x0804d9f2 in SendQuery (query=0x806a100 "select bin_data from artifact_file LIMIT 1 OFFSET 31;") at common.c:488 #6 0x0804f126 in MainLoop (source=0x40218000) at mainloop.c:425 #7 0x080504cc in main (argc=2, argv=0xbffffab4) at startup.c:305 #8 0x40100507 in __libc_start_main (main=0x804fe64 <main>, argc=2, ubp_av=0xbffffab4, init=0x8049b18 <_init>, fini=0x8057790 <_fini>, rtld_fini=0x4000dc14 <_dl_fini>, stack_end=0xbffffaac) at ../sysdeps/generic/libc-start.c:129 > Also, are you using any nondefault options for formatting psql's output? not as far as i know. i just run 'psql <DB_NAME>' and then: select bin_data from artifact_file LIMIT1 OFFSET 31; hope this provides you with what you need to help me. thanks.