Re: [BUGS] problem creating index in 6,5,3

> From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
>
> Puzzling...
>
> The lack of a core dump is probably the thing we ought to be paying
> attention to here --- most ordinary sorts of unexpected-backend-crash
> bugs should dump core.

Seems reasonable. To the extent that my frustration over this problem
has become an emotional issue, alot of that has to do with the fact
that I can't seem to get a clue what the problem is.

> One possibility is that the kernel is killing that backend process,
> most likely for having exceeded a system limit on runtime or disk blocks
> written; do you have such limits enabled on your machine? Or maybe it
> is running out of memory/swap space; how big does the process get before
> terminating?

No quotas are established. This is not the largest, nor longest
process that runs routinely on this machine. Plus, it ran under
6.5.1, but stopped running once I installed 6.5.1.

As far as machine limits, I'm pretty sure we are not reaching any.
See for yourself if you want:

========================================================================
[postgres(at)sterno webusers]$ ps -u postgres -o sz,vsz,rss,pid,time,stat,args;df -lk; ls -sk1 z* pg_so*;cat /proc/meminfo
SZ VSZ RSS PID TIME STAT COMMAND
5263 21052 1008 30040 00:00:01 S /usr/bin/postmaster -i -d 3 -B 2048 -D/var/lib/pgsql -o -S 10240
3085 12340 524 5713 00:00:00 S /opt/postgresql/bin/postmaster -p 5433 -B 1024 -S -D/opt/postgres-6.5.1-webusers-db -o -S 5120
423 1692 964 8558 00:00:00 S -bash
3349 13396 10308 8869 00:01:39 R /opt/postgresql/bin/postgres localhost webadmin webusers CREATE
421 1684 944 8873 00:00:00 S -bash
663 2652 956 8916 00:00:00 R ps -u postgres -o sz,vsz,rss,pid,time,stat,args
Filesystem 1k-blocks Used Available Use% Mounted on
/dev/sda1 1981000 1114966 763620 59% /
/dev/sda7 6123224 3344200 2462948 58% /disk/1
19608 pg_sorttemp8869.0
66184 pg_sorttemp8869.1
19352 pg_sorttemp8869.10
66184 pg_sorttemp8869.11
19480 pg_sorttemp8869.12
66152 pg_sorttemp8869.13
19640 pg_sorttemp8869.2
66184 pg_sorttemp8869.3
19416 pg_sorttemp8869.4
66184 pg_sorttemp8869.5
19384 pg_sorttemp8869.6
66184 pg_sorttemp8869.7
19576 pg_sorttemp8869.8
66184 pg_sorttemp8869.9
224072 zdaily_cookie
235708 zdaily_date_n
16 zdaily_id
total: used: free: shared: buffers: cached:
Mem: 1061101568 1058770944 2330624 59154432 383434752 615337984
Swap: 526401536 18931712 507469824
MemTotal: 1036232 kB
MemFree: 2276 kB
MemShared: 57768 kB
Buffers: 374448 kB
Cached: 600916 kB
SwapTotal: 514064 kB
SwapFree: 495576 kB
========================================================================

MemFree bounces around some, occasionally becoming rather large, but
that is an OS function. There's always plenty of swap to draw from.

The porcess size basically does not change during operation.

> Another possibility is that the backend has detected a fatal error
> condition and is doing a more-or-less-orderly shutdown. However if that
> were true then there ought to be an error message in the postmaster
> logfile; I see no such message in your prior mails.

There have been no such messages.

> Also, I just noticed that you are trying to index a "text" field.
> How long are the entries in the field? 6.5.* does not have adequate
> defenses against overly-long index entries --- the maximum safe size
> is 2700 bytes IIRC, but this isn't tested for in the current release.

Text field max size is 32 characters.

I have done a little more poking around. Just to confirm that size is
the problem, I recreated the schema and imported just 30 or so
records. Index works fine.