[BUGS] BUG #1542: pg_dump seg fault
The following bug has been logged online:
Bug reference: 1542
Logged by: Andrew Slobodyanyk
Email address: [EMAIL PROTECTED]
PostgreSQL version: 8.0.1
Operating system: linux 2.4.26, gcc 3.2.2
Description:pg_dump seg fault
Details:
After power failure any operation with tbl_test return "ERROR: could not
open relation 1663/17242/40429: No such file or directory". I try to get
information from other tables, but with or without (after deleting that
table) pg_dump crashes with seg. fault. Backtrace is:
pg_dump: reading rewrite rules
Program received signal SIGSEGV, Segmentation fault.
getRules (numRules=0x0) at pg_dump.c:3159
3159ruleinfo[i].dobj.namespace =
ruleinfo[i].ruletable->dobj.namespace;
(gdb) bt
#0 getRules (numRules=0x0) at pg_dump.c:3159
#1 0x080585e9 in getSchemaData (numTablesPtr=0x0, schemaOnly=0 '\0',
dataOnly=0 '\0') at common.c:142
#2 0x0804a88e in main (argc=3, argv=0xbd34) at pg_dump.c:559
#3 0x40138b57 in __libc_start_main () from /lib/libc.so.6
(gdb) p i
$3 = 62
(gdb) p ruleinfo[i]
$4 = {dobj = {objType = DO_RULE, catId = {tableoid = 16410, oid = 40941},
dumpId = 1237, name = 0x80785f8 "_RETURN", namespace = 0x0,
dependencies = 0x0, nDeps = 0, allocDeps = 0}, ruletable = 0x0,
ev_type = 55 '7', is_instead = 0 '\0', separate = 8 '\b'}
---(end of broadcast)---
TIP 8: explain analyze is your friend
Re: [BUGS] CC Date format code defaults to current centry
Bruce Momjian wrote:
Joe Brown wrote:
joe=> select to_date('19450323','CCYYMMDD');
to_date
2045-03-23
(1 row)
joe=> select to_date('19450323','MMDD');
to_date
1945-03-23
(1 row)
I thought the former would be "more" correct. But it seems I am mistaken.
Uh, 1945 _is_ in the 20th century, but I can see how it is confusing.
Yes, but the other way around: to_date('19450323','CCYYMMDD')
shoold be a year in the 19th century?
ps another db seems to disallow CC on input - maybe because one can
get into weird situations like to_date('2005 18',' CC') or something
similar.
Andre
---(end of broadcast)---
TIP 8: explain analyze is your friend
Re: [BUGS] BUG #1537: alter table statement
On Mon, Mar 14, 2005 at 01:20:06PM +0530, Biju wrote: > I am using postgresql version 7.2.2 As Tom observed, you might be reading documentation for a later version and are trying to do something that 7.2 doesn't support. Here's a link to the 7.2 documentation: http://www.postgresql.org/docs/7.2/interactive/index.html http://www.postgresql.org/docs/7.2/interactive/sql-altertable.html > I tried to conver the datatype of a field in a table say test. and the test > table say contains > one field testid of integer. I wanted it to convert it to say date datatype. > so i gave the query : alter table test alter testid date; The ability to change a column's type with ALTER TABLE was added in 8.0 (even so, the syntax you show is incorrect). Since you're using 7.2, you'll have to use the method mentioned in the FAQ: http://www.postgresql.org/docs/faqs.FAQ.html#4.3 However, you won't be able to cast the integer column directly to date, so you'll have to use an expression that performs the desired conversion. -- Michael Fuhr http://www.fuhr.org/~mfuhr/ ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [BUGS] BUG #1542: pg_dump seg fault
"Andrew Slobodyanyk" <[EMAIL PROTECTED]> writes: > Description:pg_dump seg fault > After power failure any operation with tbl_test return "ERROR: could not > open relation 1663/17242/40429: No such file or directory". I try to get > information from other tables, but with or without (after deleting that > table) pg_dump crashes with seg. fault. Backtrace is: > pg_dump: reading rewrite rules > Program received signal SIGSEGV, Segmentation fault. > getRules (numRules=0x0) at pg_dump.c:3159 > 3159ruleinfo[i].dobj.namespace = > ruleinfo[i].ruletable->dobj.namespace; Hmmm. What did you do to "delete that table" exactly? The crash suggests that there is a row in pg_rewrite that links to a nonexistent row in pg_class. It'd be better if pg_dump emitted a more useful failure message, of course, but the real question is how did your system catalogs get into such a state ... regards, tom lane ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
