Bug 3448

> 8.3.6 и 8.2.12
> 
[root@glav ~]#  rpm -qa | grep postgr
postgresql-8.3eter-devel-8.3.6-eter2fedora.i586
>>сзгрыз мышь
postgresql-8.3eter-docs-8.3.6-eter2fedora.i586

два дня работы, 1c77, затем при загрузке обновления (УРБД) из центра (он пока на dbf) ош:

CB  SQL State: XX000 Native: 7 Message: ERROR: could not find member 1(32914956,32914956) of opfamily 32915119; Error while executing the quer
Загрузка не выполнена! 

правка postgresql.conf и гугл к рез-ту не привели
оставил пока для теста, базу обратно слил в dbf

куда копать?

> 8.3.6 и 8.2.12
> 
[root@glav ~]#  rpm -qa | grep postgr
postgresql-8.3eter-devel-8.3.6-eter2fedora.i586
>>сзгрыз мышь
postgresql-8.3eter-docs-8.3.6-eter2fedora.i586

два дня работы, 1c77, затем при загрузке обновления (УРБД) из центра (он пока на dbf) ош:

CB  SQL State: XX000 Native: 7 Message: ERROR: could not find member 1(32914956,32914956) of opfamily 32915119; Error while executing the quer
Загрузка не выполнена! 

правка postgresql.conf и гугл к рез-ту не привели
оставил пока для теста, базу (работать то как то нада) обратно слил в dbf

куда копать?

> CB  SQL State: XX000 Native: 7 Message: ERROR: could not find member
> 1(32914956,32914956) of opfamily 32915119; Error while executing the quer

вдогонку pgstartup.log

LOG:  database system is ready to accept connections
LOG:  autovacuum launcher started
NOTICE:  ALTER TABLE / ADD PRIMARY KEY создаст подразумеваемый индекс "tmpdelrec_pkey" для таблицы "tmpdelrec"
ERROR:  could not find member 1(32914956,32914956) of opfamily 32915119
КОМАНДА:  SELECT DT.IDDOC, DT.SP5584, JOURN.ISMARK FROM DT5586 DT, _1SJOURN JOURN, TMPDELREC DELREC WHERE DELREC.TYPE=SUBSTR (CAST((DT.SP5584) as mvarchar), 1, 2) AND DELREC.MDID=SUBSTR (CAST((DT.SP5584) as mvarchar), 3, 4) AND DELREC.OBJID=SUBSTR (CAST((DT.SP5584) as mvarchar), 7, 9) AND DT.IDDOC=JOURN.IDDOC
конец файла - 1с информировала также, скл знаю плохо - хелп

Я бы вам рекомендовал попробовать советы: 
http://www.forum.mista.ru/topic.php?id=371413
хотя Вы и писали
>правка postgresql.conf и гугл к рез-ту не привели
Особенно внимательно обратите внимание, не закончилось ли у Вас место на диске. 

Собственно по топу. 
Он создан 2009-02-07.
Тут на сайте postgres'а повесили. 
http://www.postgresql.org/about/news.1055

>Please note: if you downloaded a copy of the 8.3.6 source code, or Windows build 
>8.3.6-1, from www.postgresql.org before February 4th, you may have received a 
>copy which contains a bug. Please replace it with today's download.

Если это так, надо пересобрать.

> Если это так, надо пересобрать.
> 
не так. сам же видишь что сборка от 7 февраля

> http://www.forum.mista.ru/topic.php?id=371413
пробовал все, снес-поставил postgresql-8.3eter-8.3.5-alt1.i586, работаю на fedora10, доп выяснил - нет поддержки stats_command_string = on stats_row_level = on stats_block_level = off stats_reset_on_server_start = off (не запусккается postgresql)
[root@glav ~]# /etc/init.d/postgresql start
Starting postgresql service:                                            [FAILED]
> >правка postgresql.conf и гугл к рез-ту не привели
второй раз
> закончилось ли у Вас место на диске. 
да нет же! + sysctl.conf:
vm.mmap_min_addr = 0
fs.file-max = 104854
kernel.shmall=134217728
kernel.shmmax=150829120
 
под дбф проходит (под sql с винды - спец поставлю - проверю - а надо?) - тажа база при тех же действиях (администрирование - Распределенная ИБ - автообмен - Загрузка из того же файла) без косяков.

Вопрос - а может это Selta+postgresql не поддерживает формат команды (что сиё означает тоже не знаю, но наверно что-то очень важное для УРИБ): 
  SELECT DT.IDDOC, DT.SP5584, JOURN.ISMARK FROM DT5586 DT, _1SJOURN JOURN, TMPDELREC DELREC WHERE DELREC.TYPE=SUBSTR (CAST((DT.SP5584) as mvarchar), 1, 2) AND DELREC.MDID=SUBSTR (CAST((DT.SP5584) as mvarchar), 3, 4) AND DELREC.OBJID=SUBSTR (CAST((DT.SP5584) as mvarchar), 7, 9) AND DT.IDDOC=JOURN.IDDOC

Доп.вопрос - где отключить проверку уникальности кодов справочников в Selta+postgresql ? С урибом с разных переферийных баз приходят (редко но бывает) новые записи справочников с одинаковыми кодами - дбф и mssql это проглатывают - а здесь затык - не тестировать\исправлять же центральную базу каждый день. Да и объем файлов обмена вырастет в мегабайтразы!

Разобрался в чем проблема. Можете смотреть за ее развитием http://bugs.etersoft.ru/show_bug.cgi?id=3560. 
Думаю на этой неделе сделаю багфикс. 

>Доп.вопрос - где отключить проверку уникальности кодов справочников в selta+postgresql
расскажите поподробнее что за справочник, какую ошибку выдает, что при этом делается с MSSQL.

я так понимаю что до этого, все было ужасный флуд, отношения к баге не имеющий (
Стас Вавилин, обращайтесь в саппорт в след. раз

Ко всем участникам на будущее просьба не обсуждать темы, не имеющие отношения к баге.

8.3.6 гонял на скорость (бага 3606)