Re: [BUGS] problem creating index in 6,5,3 - Mailing list pgsql-bugs

>   From: Tom Lane <tgl@sss.pgh.pa.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@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.