Thread

table schema causes crash

Thomas T. Thai <tom@minnesota.com> — 2002-12-20T18:47:27Z

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
---

Re: table schema causes crash

Bruce Momjian <pgman@candle.pha.pa.us> — 2002-12-20T18:59:35Z

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

Re: table schema causes crash

Tom Lane <tgl@sss.pgh.pa.us> — 2002-12-20T19:06:37Z

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

Re: table schema causes crash

Thomas T. Thai <tom@minnesota.com> — 2002-12-20T19:27:48Z

> 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.

Re: table schema causes crash

Tom Lane <tgl@sss.pgh.pa.us> — 2002-12-20T19:38:10Z

<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

Re: table schema causes crash

Thomas T. Thai <tom@minnesota.com> — 2002-12-20T19:49:23Z

> <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?

Re: table schema causes crash

Thomas T. Thai <tom@minnesota.com> — 2002-12-20T20:23:23Z

>> 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...

Re: table schema causes crash

Tom Lane <tgl@sss.pgh.pa.us> — 2002-12-20T20:31:49Z

<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

Re: table schema causes crash

Thomas T. Thai <tom@minnesota.com> — 2002-12-20T21:07:16Z

> <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
[...]

Re: table schema causes crash

Tom Lane <tgl@sss.pgh.pa.us> — 2002-12-20T21:18:30Z

<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

Re: table schema causes crash

Thomas T. Thai <tom@minnesota.com> — 2002-12-20T21:55:33Z

[...]
> 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)

Re: table schema causes crash

Bruce Momjian <pgman@candle.pha.pa.us> — 2002-12-20T22:11:15Z

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

Re: table schema causes crash

Thomas T. Thai <tom@minnesota.com> — 2002-12-20T22:31:31Z

> 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

Re: table schema causes crash

Thomas T. Thai <tom@minnesota.com> — 2002-12-20T22:51:40Z

>
>> 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

Re: table schema causes crash

Tom Lane <tgl@sss.pgh.pa.us> — 2002-12-20T22:55:59Z

<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

Re: table schema causes crash

Thomas T. Thai <tom@minnesota.com> — 2002-12-20T23:08:55Z

> <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.

Re: table schema causes crash

scott.marlowe <scott.marlowe@ihs.com> — 2002-12-20T23:24:29Z

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.

Re: table schema causes crash

Tom Lane <tgl@sss.pgh.pa.us> — 2002-12-20T23:37:43Z

<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

Re: table schema causes crash

Thomas T. Thai <tom@minnesota.com> — 2002-12-21T00:25:30Z

> <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.

Re: table schema causes crash

Tom Lane <tgl@sss.pgh.pa.us> — 2002-12-21T01:13:32Z

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

Re: table schema causes crash

Thomas T. Thai <tom@minnesota.com> — 2002-12-21T07:58:01Z

> 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.

Re: table schema causes crash

Bruce Momjian <pgman@candle.pha.pa.us> — 2003-01-07T22:03:36Z

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

RULE and more than 10 rewrites.

Vegard Munthe <vegard@copyleft.no> — 2003-01-22T17:17:11Z

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

Re: RULE and more than 10 rewrites.

Tom Lane <tgl@sss.pgh.pa.us> — 2003-01-22T21:40:29Z

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