Re: [BUGS] problem creating index in 6,5,3
От | Karl DeBisschop |
---|---|
Тема | Re: [BUGS] problem creating index in 6,5,3 |
Дата | |
Msg-id | 200001061535.KAA21794@skillet.infoplease.com обсуждение исходный текст |
Ответ на | Re: [BUGS] problem creating index in 6,5,3 (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: [BUGS] problem creating index in 6,5,3
(Tom Lane <tgl@sss.pgh.pa.us>)
|
Список | 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.
В списке pgsql-bugs по дате отправления:
Предыдущее
От: Bruce MomjianДата:
Сообщение: Re: [BUGS] vacuum analyze corrupts db with larger tuples (< 8k)