Thread

1. vacuum analyze fails with latest cvs version

   PostgreSQL Bugs List <pgsql-bugs@postgresql.org> — 2001-01-01T01:17:31Z

   Jukka Honkela (jukka.honkela@ee.oulu.fi) reports a bug with a severity of 2
   The lower the number the more severe it is.
   
   Short Description
   vacuum analyze fails with latest cvs version
   
   Long Description
   I have a table ('messages') of email messages (subject, sender etc..) which
   has a column (of type 'text') that contains the actual body of the
   messages. Some of these messages are longer than 8KB so the TOAST
   thing is being used.
   Problem 1: "vacuum messages;" works but "vacuum analyze messages;"
   kills the backend. Vacuum analyze worked (afaik) at least a month ago.
   Problem 2: "cluster messages_index on messages" fails on message:
   ERROR:  Tuple is too big: size 29704, max size is 8136
   The latter problem has existed as long as TOAST support has existed,
   to my experience. (Linux, RH 7.0, i386)
   
   Sample Code
   
   
   No file was uploaded with this report
   
   
   

2. Re: vacuum analyze fails with latest cvs version

   Tom Lane <tgl@sss.pgh.pa.us> — 2001-01-01T18:55:25Z

   pgsql-bugs@postgresql.org writes:
   > Problem 1: "vacuum messages;" works but "vacuum analyze messages;"
   > kills the backend.
   
   We have absolutely no hope of responding to a bug report with only
   that amount of information.  How about a backtrace from the core
   file?  How about telling us the schema for the table that's causing
   the problem?
   
   > Problem 2: "cluster messages_index on messages" fails on message:
   > ERROR:  Tuple is too big: size 29704, max size is 8136
   
   Hm.  I am not sure whether CLUSTER is bright enough to create a TOAST
   table for the new table.  Will check into it.
   
   			regards, tom lane
   
   

3. Re: vacuum analyze fails with latest cvs version

   Jukka Honkela <fatal@ees2.oulu.fi> — 2001-01-01T21:13:33Z

   On Mon, 1 Jan 2001, Tom Lane wrote:
   
   >pgsql-bugs@postgresql.org writes:
   >> Problem 1: "vacuum messages;" works but "vacuum analyze messages;"
   >> kills the backend.
   >
   >We have absolutely no hope of responding to a bug report with only
   >that amount of information.  How about a backtrace from the core
   >file?  How about telling us the schema for the table that's causing
   >the problem?
   
   
   (gdb) bt
   #0  0x40269e80 in strcoll () at strcoll.c:228
   #1  0x812301a in varstr_cmp ()
   #2  0x8123067 in text_cmp ()
   #3  0x812309a in text_lt ()
   #4  0x8135036 in FunctionCall2 ()
   #5  0x80acffd in attr_stats ()
   #6  0x80acd19 in analyze_rel ()
   #7  0x80a91fe in vac_vacuum ()
   #8  0x80a916d in vacuum ()
   #9  0x80fc06f in ProcessUtility ()
   #10 0x80fa119 in pg_exec_query_string ()
   #11 0x80fb02a in PostgresMain ()
   #12 0x80e64e8 in DoBackend ()
   #13 0x80e60b7 in BackendStartup ()
   #14 0x80e52e5 in ServerLoop ()
   #15 0x80e4ce6 in PostmasterMain ()
   #16 0x80c6818 in main ()
   
   
   
   Table "messages"
   Attribute |   Type    | Modifier
   mid       | integer   | not null default nextval('msg_id'::text)
   lid       | integer   |
   sender    | text      |
   date      | timestamp |
   subject   | text      |
   body      | text      |
   Index: messages_index
   
   
   
   Index "messages_index"
   Attribute |  Type
   -----------+---------
   lid       | integer
   mid       | integer
   btree
   
   
   select count(*) from messages;
    count
   -------
    18667
   
   
   select max(length(body)) from messages;
     max
   -------
    92148
   (1 row)
   
   This is from the stderr of the backend: (it dies on "messages" even
   it doesn't show up here)
   
   DEBUG:  Index pg_toast_18752_idx: Pages 34; Tuples 7681. CPU 0.05s/0.03u
   sec.
   DEBUG:  Analyzing...
   Server process (pid 9850) exited with status 139 at Mon Jan  1 01:43:08
   2001
   Terminating any active server processes...
   Server processes were terminated at Mon Jan  1 01:43:08 2001
   
   I didn't compile the thingy with --enable-debug, I can try with that
   too, if required?
   
   ...
   Jukka Honkela
   
   
   
   

4. Re: vacuum analyze fails with latest cvs version

   Tom Lane <tgl@sss.pgh.pa.us> — 2001-01-01T21:40:26Z

   Jukka Honkela <fatal@ees2.oulu.fi> writes:
   > I didn't compile the thingy with --enable-debug, I can try with that
   > too, if required?
   
   Yes, please.  Evidently it's dying while doing comparisons to determine
   the minimum and maximum values of one of the text columns.  It'd be
   useful to try to determine exactly which values it's comparing.
   
   			regards, tom lane