Thread: table schema causes crash
7.2.3
CREATE TABLE imap_passwd (
username varchar(128) NOT NULL PRIMARY KEY,
pw_crypt varchar(128) DEFAULT '' NOT NULL,
pw_cr varchar(128) DEFAULT '' NOT NULL,
name varchar(128) DEFAULT '' NOT NULL,
user_id int DEFAULT 65534 NOT NULL,
group_id int DEFAULT 65534 NOT NULL,
home varchar(255) DEFAULT '' NOT NULL,
maildir varchar(255) DEFAULT '' NOT NULL,
quota varchar(255) DEFAULT '' NOT NULL
);
then at the psql prompt:
\d imap_passwd
will core dump.
---
NOTICE: CREATE TABLE / PRIMARY KEY will create implicit index
'imap_passwd_pkey' for table
'imap_passwd'
CREATE
authtest=# \d imap_passwd
Segmentation fault
---
I just tried with the CVS current and don't see a crash. I don't see anything fancy in there at all. --------------------------------------------------------------------------- tom@minnesota.com wrote: > 7.2.3 > > CREATE TABLE imap_passwd ( > username varchar(128) NOT NULL PRIMARY KEY, > pw_crypt varchar(128) DEFAULT '' NOT NULL, > pw_cr varchar(128) DEFAULT '' NOT NULL, > name varchar(128) DEFAULT '' NOT NULL, > user_id int DEFAULT 65534 NOT NULL, > group_id int DEFAULT 65534 NOT NULL, > home varchar(255) DEFAULT '' NOT NULL, > maildir varchar(255) DEFAULT '' NOT NULL, > quota varchar(255) DEFAULT '' NOT NULL > ); > > then at the psql prompt: > > \d imap_passwd > > will core dump. > > --- > NOTICE: CREATE TABLE / PRIMARY KEY will create implicit index > 'imap_passwd_pkey' for table > 'imap_passwd' > CREATE > authtest=# \d imap_passwd > Segmentation fault > --- > > > > > ---------------------------(end of broadcast)--------------------------- > TIP 6: Have you searched our list archives? > > http://archives.postgresql.org > -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania 19073
Bruce Momjian <pgman@candle.pha.pa.us> writes:
> I just tried with the CVS current and don't see a crash. I don't see
> anything fancy in there at all.
Works for me in 7.2.3, as well.
How about a stack trace, platform details, etc?
regards, tom lane
> Bruce Momjian <pgman@candle.pha.pa.us> writes:
>> I just tried with the CVS current and don't see a crash. I don't see
>> anything fancy in there at all.
>
> Works for me in 7.2.3, as well.
>
> How about a stack trace, platform details, etc?
it segmentation faults but didn't core dump. postmaster is still running
though, so maybe psql segmentation fault.
# uname -a
NetBSD ns01 1.6 NetBSD 1.6 (ns01-1.6) #1: Mon Nov 25 17:03:01 CST 2002
root@ns01:/usr/s
rc/1.6/sys/arch/alpha/compile/ns01-1.6 alpha
I tried creating a test table and it suceeded w/o any problems:
create table testtable (
col_1 varchar(64) primary key,
col_2 varchar(32),
col_3 int
);
---
authtest=# create table testtable (
authtest(# col_1 varchar(64) primary key,
col_2 varchar(32),
col_3 int
);col_1 varchar(64) primary key,
authtest(# col_2 varchar(32),
authtest(# col_3 int
authtest(# );
NOTICE: CREATE TABLE / PRIMARY KEY will create implicit index
'testtable_pkey' for table '
testtable'
NOTICE: CREATE TABLE / PRIMARY KEY will create implicit index
'testtable_pkey' for table '
testtable'
CREATE
authtest=# \d testtable
Table "testtable"
Column | Type | Modifiers
--------+-----------------------+--------------
col_1 | character varying(64) | col_3 int
col_2 | character varying(32) | \d testtable
col_3 | integer | testtable
Primary key: testtable_pkey
authtest=#
---
*** NOTE \d worked above for testtable ****
then i tried creating the other table that caused it to crash again:
---
authtest=# CREATE TABLE imap_passwd (
authtest(# username varchar(128) NOT NULL PRIMARY KEY,
pw_crypt varchar(128) DEFAULT '' NOT NULL,
pw_clear varchar(128) DEFAULT '' NOT NULL,
real_name varchar(128) DEFAULT '' username
varchar(
128) NOT NULL PRIMARY KEY,
authtest(# pw_crypt varchar(128) DEFAULT '' NOT NULL,
authtest(# pw_clear varchar(128) DEFAULT '' NOT NULL,
authtest(# real_name varchar(128) DEFAULT '' NOT NULL,
authtest(# user_id int NOT NULL,
authtest(# group_id int NOT NULL,
authtest(# home varchar(255) DEFAULT '' NOT NULL,
authtest(# maildir varchar(255) DEFAULT '' NOT NULL,
authtest(# quota varchar(255) DEFAULT '' NOT NULL
authtest(# );
NOTICE: CREATE TABLE / PRIMARY KEY will create implicit index
'imap_passwd_pkey' for table
'imap_passwd'
NOTICE: CREATE TABLE / PRIMARY KEY will create implicit index
'imap_passwd_pkey' for table
'imap_passwd'
CREATE
authtest=# \d testtable
DEBUG: pq_recvbuf: unexpected EOF on client connection
Segmentation fault
$ psql authtest
Welcome to psql, the PostgreSQL interactive terminal.
Type: \copyright for distribution terms
\h for help with SQL commands
\? for help on internal slash commands
\g or terminate with semicolon to execute query
\q to quit
authtest=# \d testtable
Table "testtable"
Column | Type | Modifiers
--------+-----------------------+-----------
col_1 | character varying(64) | Primary key: testtable_pkey
*** NOTE THE OTHER MISSING COLUMNS ***
authtest=# \d imap_passwd
Table "imap_passwd"
Column | Type | Modifiers
----------+------------------------+-----------
username | character varying(128) | Primary key: imap_passwd_pkey
authtest=# drop table imap_passwd;
DROP
authtest=# \d testtable;
Table "testtable"
Column | Type | Modifiers
--------+-----------------------+-----------
col_1 | character varying(64) | Primary key: testtable_pkey
authtest=# drop table testtable;
DROP
----
as you can see the creation of table imap_passwd causes psql to
segmentation fault and causes the odd effect of '\d' command.
<tom@minnesota.com> writes:
> # uname -a
> NetBSD ns01 1.6 NetBSD 1.6 (ns01-1.6) #1: Mon Nov 25 17:03:01 CST 2002
> root@ns01:/usr/src/1.6/sys/arch/alpha/compile/ns01-1.6 alpha
Alpha, huh? I wonder if there's some 64-bit problem in psql?
But still, you haven't given us anywhere near enough information to find
the problem. I think you'll have to either get in there with a debugger
yourself, or let someone have a temporary account on your machine to
study the problem.
regards, tom lane
> <tom@minnesota.com> writes: >> # uname -a >> NetBSD ns01 1.6 NetBSD 1.6 (ns01-1.6) #1: Mon Nov 25 17:03:01 CST 2002 >> root@ns01:/usr/src/1.6/sys/arch/alpha/compile/ns01-1.6 alpha > > Alpha, huh? I wonder if there's some 64-bit problem in psql? unless something changed in psql from 7.2 to 7.2.3 that could cause 64-bit. I didn't come across this problem in 7.2. If it was a table creation problem, why didn't the creation of testtable segmentation fault? > But still, you haven't given us anywhere near enough information to find > the problem. I think you'll have to either get in there with a debugger > yourself, or let someone have a temporary account on your machine to > study the problem. I haven't much experience in using the debugger, but if you tell me how I can send you the results. If all else fail, what type of access do you need?
>> But still, you haven't given us anywhere near enough information to >> find the problem. I think you'll have to either get in there with a >> debugger yourself, or let someone have a temporary account on your >> machine to study the problem. I attached gdb to a running pid of psql. After I do: \d imap_passwd There are thousands of these lines in gdb: ... #14133 0x160034458 in _rtld_start () from /usr/libexec/ld.elf_so #14134 0x160034458 in _rtld_start () from /usr/libexec/ld.elf_so #14135 0x160034458 in _rtld_start () from /usr/libexec/ld.elf_so #14136 0x160034458 in _rtld_start () from /usr/libexec/ld.elf_so #14137 0x160034458 in _rtld_start () from /usr/libexec/ld.elf_so #14138 0x160034458 in _rtld_start () from /usr/libexec/ld.elf_so ... pressing <return> and it keeps going and going...
<tom@minnesota.com> writes:
> There are thousands of these lines in gdb:
> #14133 0x160034458 in _rtld_start () from /usr/libexec/ld.elf_so
> #14134 0x160034458 in _rtld_start () from /usr/libexec/ld.elf_so
> #14135 0x160034458 in _rtld_start () from /usr/libexec/ld.elf_so
I'd say the thing is already hosed at this point --- can you dig
down to the bottom of the call stack and see what's under the infinite
recursion?
regards, tom lane
> <tom@minnesota.com> writes: >> There are thousands of these lines in gdb: >> #14133 0x160034458 in _rtld_start () from /usr/libexec/ld.elf_so >> #14134 0x160034458 in _rtld_start () from /usr/libexec/ld.elf_so >> #14135 0x160034458 in _rtld_start () from /usr/libexec/ld.elf_so > > I'd say the thing is already hosed at this point --- can you dig > down to the bottom of the call stack and see what's under the infinite > recursion? (gdb) bt #0 0x160275d84 in strlen () from /usr/lib/libc.so.12 #1 0x120010a10 in print_aligned_text () #2 0x120012ea8 in printTable () #3 0x120015a94 in describeTableDetails () #4 0x1200041f0 in exec_command () #5 0x120003a50 in HandleSlashCmds () #6 0x12000bb8c in MainLoop () #7 0x12000d974 in main () #8 0x1200036a4 in __start () #9 0x160034458 in _rtld_start () from /usr/libexec/ld.elf_so #10 0x160034458 in _rtld_start () from /usr/libexec/ld.elf_so #11 0x160034458 in _rtld_start () from /usr/libexec/ld.elf_so #12 0x160034458 in _rtld_start () from /usr/libexec/ld.elf_so [...]
<tom@minnesota.com> writes:
> (gdb) bt
> #0 0x160275d84 in strlen () from /usr/lib/libc.so.12
> #1 0x120010a10 in print_aligned_text ()
> #2 0x120012ea8 in printTable ()
> #3 0x120015a94 in describeTableDetails ()
> #4 0x1200041f0 in exec_command ()
> #5 0x120003a50 in HandleSlashCmds ()
> #6 0x12000bb8c in MainLoop ()
> #7 0x12000d974 in main ()
Hmm. Evidently a null (or invalid) pointer is getting passed to
strlen(), but it's hard to say more without a symbolic backtrace
--- for which you'll need to recompile psql with debug symbols.
We've found a number of bugs in print_aligned_text() in the past, but
the only post-7.2 fixes I see in the logs have to do with zero-column
tables; it seems unlikely that \d is triggering those bugs. Possibly
you've found something new.
regards, tom lane
[...]
> Hmm. Evidently a null (or invalid) pointer is getting passed to
> strlen(), but it's hard to say more without a symbolic backtrace
> --- for which you'll need to recompile psql with debug symbols.
[...]
I recompiled psql with debug.
---
Program received signal SIGSEGV, Segmentation fault.
0x160275d84 in strlen () from /usr/lib/libc.so.12
(gdb) bt
#0 0x160275d84 in strlen () from /usr/lib/libc.so.12
#1 0x120010a10 in print_aligned_text (
title=0x120036580 "Table \"imap_passwd\"", headers=0x1fffff510,
cells=0x120036100, footers=0x12003a460, opt_align=0x120020d16 "llll",
opt_barebones=0 '\000', opt_border=1, fout=0x160293568) at print.c:280
#2 0x120012ea8 in printTable (title=0x120036580 "Table \"imap_passwd\"",
headers=0x1fffff510, cells=0x120036100, footers=0x12003a460,
align=0x120020d16 "llll", opt=0x1fffff4e8, fout=0x160293568)
at print.c:1123
#3 0x120015a94 in describeTableDetails (name=0x120020cc4 "Primary key",
desc=0 '\000') at describe.c:914
#4 0x1200041f0 in exec_command (cmd=0x12003a430 "d",
options_string=0x12003a432 "imap_passwd", continue_parse=0x1fffff6e0,
query_buf=0x1200389e0) at command.c:347
#5 0x120003a50 in HandleSlashCmds (line=0x12003a3b1 "d imap_passwd",
query_buf=0x1200389e0, end_of_cmd=0x1fffff750) at command.c:135
#6 0x12000bb8c in MainLoop (source=0x1602934d0) at mainloop.c:467
#7 0x12000d974 in main (argc=1613313248, argv=0x12001ea33) at startup.c:305
(gdb)
Let me ask --- if you execute \a, then \d in psql, does it display OK? How about \x and then \d? --------------------------------------------------------------------------- tom@minnesota.com wrote: > [...] > > Hmm. Evidently a null (or invalid) pointer is getting passed to > > strlen(), but it's hard to say more without a symbolic backtrace > > --- for which you'll need to recompile psql with debug symbols. > [...] > > I recompiled psql with debug. > > --- > Program received signal SIGSEGV, Segmentation fault. > 0x160275d84 in strlen () from /usr/lib/libc.so.12 > (gdb) bt > #0 0x160275d84 in strlen () from /usr/lib/libc.so.12 > #1 0x120010a10 in print_aligned_text ( > title=0x120036580 "Table \"imap_passwd\"", headers=0x1fffff510, > cells=0x120036100, footers=0x12003a460, opt_align=0x120020d16 "llll", > opt_barebones=0 '\000', opt_border=1, fout=0x160293568) at print.c:280 > #2 0x120012ea8 in printTable (title=0x120036580 "Table \"imap_passwd\"", > headers=0x1fffff510, cells=0x120036100, footers=0x12003a460, > align=0x120020d16 "llll", opt=0x1fffff4e8, fout=0x160293568) > at print.c:1123 > #3 0x120015a94 in describeTableDetails (name=0x120020cc4 "Primary key", > desc=0 '\000') at describe.c:914 > #4 0x1200041f0 in exec_command (cmd=0x12003a430 "d", > options_string=0x12003a432 "imap_passwd", continue_parse=0x1fffff6e0, > query_buf=0x1200389e0) at command.c:347 > #5 0x120003a50 in HandleSlashCmds (line=0x12003a3b1 "d imap_passwd", > query_buf=0x1200389e0, end_of_cmd=0x1fffff750) at command.c:135 > #6 0x12000bb8c in MainLoop (source=0x1602934d0) at mainloop.c:467 > #7 0x12000d974 in main (argc=1613313248, argv=0x12001ea33) at startup.c:305 > (gdb) > > > > ---------------------------(end of broadcast)--------------------------- > TIP 6: Have you searched our list archives? > > http://archives.postgresql.org > -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania 19073
> Let me ask --- if you execute \a, then \d in psql, does it display OK?
> How about \x and then \d?
I created the table as described earlier, it segmentation fault. I ran
psql again, then:
authtest=# \d imap_passwd
Table "imap_passwd"
Column | Type | Modifiers
----------+------------------------+-----------
username | character varying(128) | Primary key: imap_passwd_pkey
*** NOTE: it only shows the first column and none of the other columns ***
authtest=# \a
Output format is unaligned.
authtest=# \a
Output format is aligned.
authtest=# \d imap_passwd
Table "imap_passwd"
Column | Type | Modifiers
----------+------------------------+-----------
username | character varying(128) | Primary key: imap_passwd_pkey
authtest=# \a
Output format is unaligned.
authtest=# \d imap_passwd
Table "imap_passwd"
Column|Type|Modifiers
username|character varying(128)|Primary key: imap_passwd_pkey
authtest=# \x
Expanded display is on.
authtest=# \d imap_passwd
Table "imap_passwd"
Column|username
Type|character varying(128)
Primary key: imap_passwd_pkey
authtest=# \x
Expanded display is off.
authtest=# \d imap_passwd
Table "imap_passwd"
Column|Type|Modifiers
username|character varying(128)|Primary key: imap_passwd_pkey
authtest=# drop table imap_passwd;
DROP
authtest=# CREATE TABLE imap_passwd (
authtest(# username varchar(128) PRIMARY KEY,
pw_crypt varchar(128) DEFAULT '' NOT NULL,
pw_clear varchar(128) DEFAULT '' NOT NULL,
real_name varchar(128) DEFAULT '' NOT NULL,
user_id int DEFAULT '65534' NOT NULL,
group_id int DEFAULT '65534' NOT N username
varcha
r(128) PRIMARY KEY,
authtest(# pw_crypt varchar(128) DEFAULT '' NOT NULL,
authtest(# pw_clear varchar(128) DEFAULT '' NOT NULL,
authtest(# real_name varchar(128) DEFAULT '' NOT NULL,
authtest(# user_id int DEFAULT '65534' NOT NULL,
authtest(# group_id int DEFAULT '65534' NOT NULL,
authtest(# home varchar(255) DEFAULT '' NOT NULL,
authtest(# maildir varchar(255) DEFAULT '' NOT NULL,
authtest(# quota varchar(255) DEFAULT '' NOT NULL
authtest(# );
NOTICE: CREATE TABLE / PRIMARY KEY will create implicit index
'imap_passwd_pkey' for table
'imap_passwd'
CREATE
authtest=# \d imap_passwd
Table "imap_passwd"
Column|Type|Modifiers
Segmentation fault
***
NOTE: it only crashes when \d imap_passwd AFTER fresh new create of
imap_passwd
***
---------------------------------------------------------------------------
>
> tom@minnesota.com wrote:
>> [...]
>> > Hmm. Evidently a null (or invalid) pointer is getting passed to
>> strlen(), but it's hard to say more without a symbolic backtrace ---
>> for which you'll need to recompile psql with debug symbols.
>> [...]
>>
>> I recompiled psql with debug.
>>
>> ---
>> Program received signal SIGSEGV, Segmentation fault.
>> 0x160275d84 in strlen () from /usr/lib/libc.so.12
>> (gdb) bt
>> #0 0x160275d84 in strlen () from /usr/lib/libc.so.12
>> #1 0x120010a10 in print_aligned_text (
>> title=0x120036580 "Table \"imap_passwd\"", headers=0x1fffff510,
>> cells=0x120036100, footers=0x12003a460, opt_align=0x120020d16
>> "llll", opt_barebones=0 '\000', opt_border=1, fout=0x160293568) at
>> print.c:280
>> #2 0x120012ea8 in printTable (title=0x120036580 "Table
>> \"imap_passwd\"",
>> headers=0x1fffff510, cells=0x120036100, footers=0x12003a460,
>> align=0x120020d16 "llll", opt=0x1fffff4e8, fout=0x160293568) at
>> print.c:1123
>> #3 0x120015a94 in describeTableDetails (name=0x120020cc4 "Primary
>> key",
>> desc=0 '\000') at describe.c:914
>> #4 0x1200041f0 in exec_command (cmd=0x12003a430 "d",
>> options_string=0x12003a432 "imap_passwd",
>> continue_parse=0x1fffff6e0, query_buf=0x1200389e0) at
>> command.c:347
>> #5 0x120003a50 in HandleSlashCmds (line=0x12003a3b1 "d imap_passwd",
>> query_buf=0x1200389e0, end_of_cmd=0x1fffff750) at command.c:135
>> #6 0x12000bb8c in MainLoop (source=0x1602934d0) at mainloop.c:467 #7
>> 0x12000d974 in main (argc=1613313248, argv=0x12001ea33) at
>> startup.c:305 (gdb)
>>
>>
>>
>> ---------------------------(end of
>> broadcast)--------------------------- TIP 6: Have you searched our
>> list archives?
>>
>> http://archives.postgresql.org
>>
>
> --
> Bruce Momjian | http://candle.pha.pa.us
> pgman@candle.pha.pa.us | (610) 359-1001
> + If your life is a hard drive, | 13 Roberts Road
> + Christ can be your backup. | Newtown Square, Pennsylvania
> 19073
>
>> Let me ask --- if you execute \a, then \d in psql, does it display OK?
>> How about \x and then \d?
>
> I created the table as described earlier, it segmentation fault. I ran
> psql again, then:
>
> authtest=# \d imap_passwd
> Table "imap_passwd"
> Column | Type | Modifiers
> ----------+------------------------+-----------
> username | character varying(128) | Primary key: imap_passwd_pkey
>
> *** NOTE: it only shows the first column and none of the other columns
> ***
[...]
After doing more \d on various tables, it finally core dumped on the psql
binary with debug symbols:
This GDB was configured as "alpha-unknown-netbsd"...
Core was generated by `psql'.
Program terminated with signal 11, Segmentation fault.
Reading symbols from /usr/libexec/ld.elf_so...done.
Loaded symbols for /usr/libexec/ld.elf_so
Reading symbols from /usr/local/lib/libpq.so.2...done.
Loaded symbols for /usr/local/lib/libpq.so.2
Reading symbols from /usr/lib/libz.so.0...done.
Loaded symbols for /usr/lib/libz.so.0
Reading symbols from /usr/lib/libcrypt.so.0...done.
Loaded symbols for /usr/lib/libcrypt.so.0
Reading symbols from /usr/lib/libresolv.so.1...done.
Loaded symbols for /usr/lib/libresolv.so.1
Reading symbols from /usr/lib/libm.so.0...done.
Loaded symbols for /usr/lib/libm.so.0
Reading symbols from /usr/lib/libutil.so.6...done.
Loaded symbols for /usr/lib/libutil.so.6
Reading symbols from /usr/lib/libedit.so.2...done.
Loaded symbols for /usr/lib/libedit.so.2
Reading symbols from /usr/lib/libcurses.so.5...done.
Loaded symbols for /usr/lib/libcurses.so.5
Reading symbols from /usr/lib/libc.so.12...done.
Loaded symbols for /usr/lib/libc.so.12
#0 0x160275d84 in strlen () from /usr/lib/libc.so.12
(gdb) bt
#0 0x160275d84 in strlen () from /usr/lib/libc.so.12
#1 0x120010a10 in print_aligned_text (title=0x120015a94 "\002", headers=0xc,
cells=0x12003a550, footers=0x0, opt_align=0x120020cc4 "Primary key",
opt_barebones=1 '\001', opt_border=0, fout=0x12003a540) at print.c:280
<tom@minnesota.com> writes:
> authtest=# \d imap_passwd
> Table "imap_passwd"
> Column | Type | Modifiers
> ----------+------------------------+-----------
> username | character varying(128) | Primary key: imap_passwd_pkey
> *** NOTE: it only shows the first column and none of the other columns ***
What I find even more suspicious is that the "Primary key" footer shows
up in the table data area. Looking at print_aligned_text, this seems to
suggest that cells[2] must be NULL --- you would get this kind of
mistake if the number of non-null cells[] entries is not a multiple of
the number of non-null headers[] entries. But I surely do not see how
describeTableDetails would be setting that cell to null --- it does
cells[i * cols + 2] = xmalloc(128 + 128);
and xmalloc() will exit() rather than return null.
regards, tom lane
> <tom@minnesota.com> writes:
>> authtest=# \d imap_passwd
>> Table "imap_passwd"
>> Column | Type | Modifiers
>> ----------+------------------------+-----------
>> username | character varying(128) | Primary key: imap_passwd_pkey
>
>> *** NOTE: it only shows the first column and none of the other columns
>> ***
>
> What I find even more suspicious is that the "Primary key" footer shows
> up in the table data area. Looking at print_aligned_text, this seems to
[...]
\d on any table shows only the first column:
authtest=# \d country
Table "country"
Column | Type | Modifiers
------------+---------+-----------
country_id | integer | Primary key: country_pkey
authtest=# \d auth_address
Table "auth_address"
Column | Type | Modifiers
------------+---------+-----------
address_id | integer | Primary key: auth_address_pkey
Unique keys: auth_address_user_id_key
Triggers: RI_ConstraintTrigger_9306303,
RI_ConstraintTrigger_9306352,
RI_ConstraintTrigger_9306354
authtest=# \d auth_email
Table "auth_email"
Column | Type | Modifiers
----------+---------+-----------
email_id | integer | Primary key: auth_email_pkey
Unique keys: auth_email_em_idx,
auth_email_ev_idx,
auth_email_user_id_key
Triggers: RI_ConstraintTrigger_9324514
---
All of the above table came from the same db. However, when I connect to a
different database, things are normal again:
authtest=# \c transition
You are now connected to database transition.
transition=# \d t_blocks
Table "t_blocks"
Column | Type | Modifiers
--------------+--------------------------+-----------
rid | character varying(16) | atthasdef
display | character(1) | É
heading | character varying(48) |
content | text | ter(1)
url | character varying(96) |
type | smallint |
birthstamp | timestamp with time zone | pgsql
timestamp | timestamp with time zone | l
showmain | character(1) | Ë
hits | integer |
cache | integer |
pagecomments | character(1) |
orderid | smallint | zone
Primary key: t_blocks_pkey
---
But note the Modifiers column. There are some very odd values in there.
Could it be related to the fact that in 7.2 and earlier, didn't use the flag:
--enable-multibyte
I only started using --enable-multibyte in 7.2.3.
On Fri, 20 Dec 2002, Tom Lane wrote: > <tom@minnesota.com> writes: > > authtest=# \d imap_passwd > > Table "imap_passwd" > > Column | Type | Modifiers > > ----------+------------------------+----------- > > username | character varying(128) | Primary key: imap_passwd_pkey > > > *** NOTE: it only shows the first column and none of the other columns *** > > What I find even more suspicious is that the "Primary key" footer shows > up in the table data area. Looking at print_aligned_text, this seems to > suggest that cells[2] must be NULL --- you would get this kind of > mistake if the number of non-null cells[] entries is not a multiple of > the number of non-null headers[] entries. But I surely do not see how > describeTableDetails would be setting that cell to null --- it does > > cells[i * cols + 2] = xmalloc(128 + 128); > > and xmalloc() will exit() rather than return null. This is sounding more and more like a machine with bad memory or a bad hard drive.
<tom@minnesota.com> writes:
> Could it be related to the fact that in 7.2 and earlier, didn't use the flag:
> --enable-multibyte
> I only started using --enable-multibyte in 7.2.3.
Oh? Are you sure you've been consistent about using --enable-multibyte?
I am suddenly wondering about the possible consequences of psql compiled
with multibyte used with a libpq.so compiled without, or vice versa.
I don't believe that we'd see these consequences for psql and backend
not compiled the same way; those combinations are reasonably well
tested. I'm less sure about psql-to-libpq.so incompatibilities, though.
regards, tom lane
> <tom@minnesota.com> writes: >> Could it be related to the fact that in 7.2 and earlier, didn't use >> the flag: --enable-multibyte >> I only started using --enable-multibyte in 7.2.3. > > Oh? Are you sure you've been consistent about using --enable-multibyte? I'm pretty sure. All installtions from 7.2 and before didn't have --enable-multibyte, while 7.2.3 has it configured with that option. > I am suddenly wondering about the possible consequences of psql compiled > with multibyte used with a libpq.so compiled without, or vice versa. the pgsql i used with debug has --enable-multibyte, as well as libpg.so.
While studying this I noticed a number of potential buffer overruns in
the 7.2.3 version of describeTableDetails(). They were mostly fixed
already in 7.3, and I just committed a fix for one more. However,
I do not believe that any of these overruns could have occurred in the
example you give, so there's still something fishy going on. On the
whole, I'd still bet that it's a 64-bit-platform issue. But where?
Good luck digging...
regards, tom lane
> While studying this I noticed a number of potential buffer overruns in > the 7.2.3 version of describeTableDetails(). They were mostly fixed > already in 7.3, and I just committed a fix for one more. However, I do > not believe that any of these overruns could have occurred in the > example you give, so there's still something fishy going on. On the > whole, I'd still bet that it's a 64-bit-platform issue. But where? Good > luck digging... I compiled 7.3 and ran it on port 5454 while 7.2.3 was using 5432. On 7.3 the table was created and displayed normally without a segmentation fault. Apparantly the bug fixes you committed between 7.2.3 and 7.3 fixed the problem. Thank you.
Was a cause ever found for this? --------------------------------------------------------------------------- tom@minnesota.com wrote: > > <tom@minnesota.com> writes: > >> authtest=# \d imap_passwd > >> Table "imap_passwd" > >> Column | Type | Modifiers > >> ----------+------------------------+----------- > >> username | character varying(128) | Primary key: imap_passwd_pkey > > > >> *** NOTE: it only shows the first column and none of the other columns > >> *** > > > > What I find even more suspicious is that the "Primary key" footer shows > > up in the table data area. Looking at print_aligned_text, this seems to > [...] > > \d on any table shows only the first column: > > authtest=# \d country > Table "country" > Column | Type | Modifiers > ------------+---------+----------- > country_id | integer | Primary key: country_pkey > > authtest=# \d auth_address > Table "auth_address" > Column | Type | Modifiers > ------------+---------+----------- > address_id | integer | Primary key: auth_address_pkey > Unique keys: auth_address_user_id_key > Triggers: RI_ConstraintTrigger_9306303, > RI_ConstraintTrigger_9306352, > RI_ConstraintTrigger_9306354 > > authtest=# \d auth_email > Table "auth_email" > Column | Type | Modifiers > ----------+---------+----------- > email_id | integer | Primary key: auth_email_pkey > Unique keys: auth_email_em_idx, > auth_email_ev_idx, > auth_email_user_id_key > Triggers: RI_ConstraintTrigger_9324514 > > --- > > All of the above table came from the same db. However, when I connect to a > different database, things are normal again: > > authtest=# \c transition > You are now connected to database transition. > transition=# \d t_blocks > Table "t_blocks" > Column | Type | Modifiers > --------------+--------------------------+----------- > rid | character varying(16) | atthasdef > display | character(1) | ? > heading | character varying(48) | > content | text | ter(1) > url | character varying(96) | > type | smallint | > birthstamp | timestamp with time zone | pgsql > timestamp | timestamp with time zone | l > showmain | character(1) | ? > hits | integer | > cache | integer | > pagecomments | character(1) | > orderid | smallint | zone > Primary key: t_blocks_pkey > > --- > But note the Modifiers column. There are some very odd values in there. > > Could it be related to the fact that in 7.2 and earlier, didn't use the flag: > > --enable-multibyte > > I only started using --enable-multibyte in 7.2.3. > > > -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania 19073
I have a RULE that does 18 rewrites. This is a RULE that saves me alot of
work when rewriting some software, but the RULE always fails since PGSQL
seems tp think 10 or more rewrites constitutes a loop.
"ERROR: query rewritten 10 times, may contain cycles"
Is there any way I can set the rewrite limit to more than 10, say 100,
which would be more of a safeguard number for loops?
If not, should I use a trigger on the view the RULE is working on at the
moment?
For those interested my rule looks like this:
---
CREATE RULE person_update AS ON UPDATE TO person_view DO INSTEAD
(
UPDATE attribute SET value = new.firstname WHERE
attrtype = 'firstname' AND objectid = old.id;
UPDATE attribute SET value = new.middlename WHERE
attrtype = 'middlename' AND objectid = old.id;
UPDATE attribute SET value = new.lastname WHERE
attrtype = 'lastname' AND objectid = old.id;
UPDATE attribute SET value = new.nickname WHERE
attrtype = 'nickname' AND objectid = old.id;
UPDATE attribute SET value = new.membernumber WHERE
attrtype = 'membernumber' AND objectid = old.id;
UPDATE attribute SET value = new.streetaddress WHERE
attrtype = 'streetaddress' AND objectid = old.id;
UPDATE attribute SET value = new.zipcode WHERE
attrtype = 'zipcode' AND objectid = old.id;
UPDATE attribute SET value = new.city WHERE
attrtype = 'city' AND objectid = old.id;
UPDATE attribute SET value = new.country WHERE
attrtype = 'country' AND objectid = old.id;
UPDATE attribute SET value = new.phone WHERE
attrtype = 'phone' AND objectid = old.id;
UPDATE attribute SET value = new.email WHERE
attrtype = 'e-mail' AND objectid = old.id;
UPDATE attribute SET value = new.mobilephone WHERE
attrtype = 'mobilephone' AND objectid = old.id;
UPDATE attribute SET value = new.dept WHERE
attrtype = 'dept' AND objectid = old.id;
UPDATE attribute SET value = new.fromdate WHERE
attrtype = 'fromdate' AND objectid = old.id;
UPDATE attribute SET value = new.birthday WHERE
attrtype = 'birthday' AND objectid = old.id;
UPDATE attribute SET value = new.username WHERE
attrtype = 'username' AND objectid = old.id;
UPDATE attribute SET value = new.password WHERE
attrtype = 'password' AND objectid = old.id;
UPDATE attribute SET value = new.language WHERE
attrtype = 'language' AND objectid = old.id
);
---
(Pretty ugly huh?)
-- Vegard Munthe
Vegard Munthe <vegard@copyleft.no> writes:
> I have a RULE that does 18 rewrites. This is a RULE that saves me alot of
> work when rewriting some software, but the RULE always fails since PGSQL
> seems tp think 10 or more rewrites constitutes a loop.
> "ERROR: query rewritten 10 times, may contain cycles"
> Is there any way I can set the rewrite limit to more than 10, say 100,
> which would be more of a safeguard number for loops?
Well, you could alter the value by hand in src/backend/rewrite/rewriteHandler.c
... or you could upgrade to 7.3, wherein the default limit is 100.
regards, tom lane