Глюк с LinCash (срочно)!

[Бродяга_Джон]

Примерно так:
Вчера делали учёт на одной точке, часть забили на ДК, с ноута вторую часть закинули. Опосля, исправляя "тормоза" при работе, выгружаю БД товара и пытаюсь её тут же загрузить, облом.
Ладно, вспоминаю рецепт от прошлого года по этому поводу, создание базы через sudo, ага, снова облом типа чего-то там в 11511 не того (не помню по англицки дословно, и не записал и смысл не вникал тогда.
Ладно, сделал реиндексацию LinCash, перезагрузил, ещё раз реиндексацию и вроде нормально стало, без "тормозов", успокоился.
Сегодня работать они начали нормально, а вот глюк вылез когда пытались товар с флешки загрузить, не прокатило, а логе - ошибка загрузки на все строки товара. Ладно, добрался до них после обеда, увидел про ошибки в логе - полез файл смотреть, с файлом всё в порядке. Думаю ладно, добью количество через справочник товара, а вот тут-то и оппа, она, засада.
В карточке товара меняю количество, тыкаю кнопку "Сохранить" и фиг вам полный, ноль реакции.
Полез в постгри.
говорю ему "\d"
а он в ответ - invalid page header in block 8 of relation "pg_proc"
в ответ на "\d pg_pro" он -
Таблица "pg_catalog.pg_proc"
Колонка | Тип | Модификаторы
----------------+-----------+--------------
proname | name | not null
pronamespace | oid | not null
proowner | oid | not null
prolang | oid | not null
procost | real | not null
prorows | real | not null
proisagg | boolean | not null
prosecdef | boolean | not null
proisstrict | boolean | not null
proretset | boolean | not null
provolatile | "char" | not null
pronargs | smallint | not null
prorettype | oid | not null
proargtypes | oidvector | not null
proallargtypes | oid[] |
proargmodes | "char"[] |
proargnames | text[] |
prosrc | text |
probin | bytea |
proconfig | text[] |
proacl | aclitem[] |
Индексы:
"pg_proc_oid_index" UNIQUE, btree (oid)
"pg_proc_proname_args_nsp_index" UNIQUE, btree (proname, proargtypes, pronamespace)

идентичный ответ, "invalid page header in block 8 of relation "pg_proc"", и на попытку реиндексации БД товара

и ещё он не экспортирует LinCash теперь

куды копать-рыть? надобно срочно

[Alexander]

invalid page header in block 8 of relation "pg_proc"

Любой гугль Вам скажет, что это проблемы с служебной базой PostgreSQL.
Если с жестким диском все в порядке и с файловой системой на разделе - тоже, то следует пересоздать служебные базы postgresql.
Ну или просто снести PostgreSQL и поставить его заново.
Потом выполнить createdb LinCash, createdb Transaction и загрузить в них дампы.

[Бродяга_Джон]

invalid page header in block 8 of relation "pg_proc"

Любой гугль Вам скажет, что это проблемы с служебной базой PostgreSQL.
Если с жестким диском все в порядке и с файловой системой на разделе - тоже, то следует пересоздать служебные базы postgresql.
Ну или просто снести PostgreSQL и поставит его заново.
Потом выполнить createdb LinCash, createdb Transaction и загрузить в них дампы.

да не рыл ещё гугля
ток домой приехал и отписался, на точке инета нет

хард в норме, ошибок фс нет (проверял)

[Alexander]

хард в норме, ошибок фс нет (проверял)

Насколько я понимаю, вылечить конкретную базу шансов очень мало.

[Бродяга_Джон]

хард в норме, ошибок фс нет (проверял)

Насколько я понимаю, вылечить конкретную базу шансов очень мало.

но блин торговля то идёт

[Alexander]

Ну значит выгрузить последний отчет и переставить PostgreSQL.
Лучше ему уже точно не станет.
На самом деле пару раз сталкивались с такой ерундой.
Причем на таблице транзакций (даже не на служебной базе постгреса, как в Вашем случае, а на самой БД Transaction). Если бы не бэкапы и не спец. сборка демона выгрузки, то данные могли бы потеряться окончательно.
Все мои копания на форумах на эту тему никаких рецептов лечения не выявили.
Разве что в предыдущих случаях PostgreSQL не пришлось сносить - дело ограничилось пересозданием БД.
Кстати и дампы при таких сбоях перестают работать нормально (обрываются на сбойном блоке).

[Бродяга_Джон]

Ну значит выгрузить последний отчет и переставить PostgreSQL.
Лучше ему уже точно не станет.
На самом деле пару раз сталкивались с такой ерундой.
Причем на таблице транзакций (даже не на служебной базе постгреса, как в Вашем случае, а на самой БД Transaction). Если бы не бэкапы и не спец. сборка демона выгрузки, то данные могли бы потеряться окончательно.
Все мои копания на форумах на эту тему никаких рецептов лечения не выявили.
Разве что в предыдущих случаях PostgreSQL не пришлось сносить - дело ограничилось пересозданием БД.
Кстати и дампы при таких сбоях перестают работать нормально (обрываются на сбойном блоке).

тут в одном аспекте нам легче, как раз учёт сделали
надо будет всего лишь продажи за день на крайняк учесть из файла регистрации

[Alexander]

Решился вопрос?

[Бродяга_Джон]

Ну в плане работы - решился, схитрил, заменив ssd на обычный хард и переустановив заново, подгрузив бэкапы с конца учёта.

А ssd снял, пока оставил как он есть, будет время - погляжу.
Смущает то что через карточку товара нельзя например кол-во отредактировать, а продажи спокойно идут, минусует товар.

на текущий момент каталог 11511 совсем пуст