ERROR: cannot open segment 3 of relation ip_to_locations_p1_idx (target block 537398): No such file or directory

mwolf
Дата: 28.09.2004 14:56:58
Есть программа на Яве.
Берёт данные из одной таблицы, обрабатывает их, вставляет в другую.
Программа эта выполняется из скрипта создания базы по типу:
\! ./название_программы
Всё было нормально до одного момента вчера , когда вылезла вот такая ошибка:
insertDBALoc method (e1) :ERROR:  HASH: Out of overflow pages.  Out of luck.
insertDBALoc method (e1) :ERROR: current transaction is aborted, queries ignored until end of transaction block
insertDBALoc method (e1) :ERROR: current transaction is aborted, queries ignored until end of transaction block
...
Последняя строка вылазит пока по Ctrl+c не снимешь программу.
Когда попробовал запустить сегодня, вылезло это:
ERROR:  cannot open segment 3 of relation ip_to_locations_p1_idx (target block 537398): No such file or directory
insertDBALoc method (e1) :ERROR: current transaction is aborted, queries ignored until end of transaction block
insertDBALoc method (e1) :ERROR: current transaction is aborted, queries ignored until end of transaction block
...
Здесь ip_to_locations_p1_idx - индекс на таблице ip_to_locations. Её, родимую, как раз и заполняет программа.
Где проблема? Винту каюк? Или в Яве или её драйвере где-то глючит?
Таблицу и индекс я пересоздавал.
Shweik
Дата: 28.09.2004 15:19:48
Попробуй сделать что-то вроде
pg_dump -f mydb.sql mydb &&
dropdb mydb && create db mydb &&
psql -f mydb.sql mydb
Может винту и не каюк но что-то было неладно
с записью страниц. Я бы обратил внимание на состояние оперативки.
Ну и конечно если PG под какой-то виндой крутится -
ничего странного - нормальный глюк.
mwolf
Дата: 28.09.2004 16:10:30
Shweik
Попробуй сделать что-то вроде
pg_dump -f mydb.sql mydb &&
dropdb mydb && create db mydb &&
psql -f mydb.sql mydb

Зачем? Пересоздать базу? Скрипты и так есть. Базу раз в день пересоздают - проект программеры отлаживают.

Shweik
Может винту и не каюк

Оптимист )))

Shweik
но что-то было неладно
с записью страниц. Я бы обратил внимание на состояние оперативки.

Верх команды top
15:06:56  up 21 days,  1:21,  9 users,  load average: 2.55, 1.61, 0.81
163 processes: 157 sleeping, 6 running, 0 zombie, 0 stopped
CPU states: 91.3% user 8.6% system 0.0% nice 0.0% iowait 0.0% idle
Mem: 904788k av, 845216k used, 59572k free, 0k shrd, 6696k buff
394304k active, 412876k inactive
Swap: 2048276k av, 933928k used, 1114348k free 571520k cached

PID USER PRI NI SIZE RSS SHARE STAT %CPU %MEM TIME CPU COMMAND
10387 postgres 9 0 201M 201M 199M S 0.0 22.7 0:58 0 postmaster
10434 postgres 16 0 195M 195M 194M R 54.4 22.1 1:36 0 postmaster
9933 root 9 0 124M 124M 23468 S 0.0 14.1 1:10 0 java
Shweik
Ну и конечно если PG под какой-то виндой крутится -
ничего странного - нормальный глюк.

Линух
Sad Spirit
Дата: 29.09.2004 10:40:30
mwolf
Здесь ip_to_locations_p1_idx - индекс на таблице ip_to_locations.

А индекс какого типа? Не hash случайно:
mwolf

insertDBALoc method (e1) :ERROR: HASH: Out of overflow pages. Out of luck.

Потому что с такими индексами есть проблемы и их использовать сами разработчики не очень рекомендуют.
mwolf
Дата: 29.09.2004 11:53:15
Sad Spirit
mwolf
Здесь ip_to_locations_p1_idx - индекс на таблице ip_to_locations.

А индекс какого типа? Не hash случайно:
mwolf

insertDBALoc method (e1) :ERROR: HASH: Out of overflow pages. Out of luck.

Потому что с такими индексами есть проблемы и их использовать сами разработчики не очень рекомендуют.


Ой, а как ты догадался? )))
Индекс действительно hash. Где-то вычитал, что индексы этого типа ОЧЕНЬ хорошо работает на поиск по =, вот и воткнул его. Так что переделать его в btree?

Я пересоздал базу ещё раз. Всё нормально создалось и нормально работает (тфу-тфу-тфу). Хотя конечно хотелось бы узнать, что собсно произошло.
Sad Spirit
Дата: 29.09.2004 13:24:51
mwolf
Где-то вычитал, что индексы этого типа ОЧЕНЬ хорошо работает на поиск по =, вот и воткнул его.


Не знаю где ты это вычитал, но вот официальная документация говорит следующее:
документация
Note: Testing has shown PostgreSQL's hash indexes to perform no better than B-tree indexes, and the index size and build time for hash indexes is much worse. For these reasons, hash index use is presently discouraged