Thread: vacuum analyze fails with latest cvs version

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

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

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

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