Добрый день. Друзья, подскажите пожалуйста. В таблице есть поле, которое

является первичным ключем. Но значения этого поля — не уникальны.
Как такое может быть?

\d таблица
code | integer | | not null | nextval(....)
...
Indexes:
"pbl_base_pkey" PRIMARY KEY, btree (code)

Выборка:
code | count
-------+-------
14284 | 2
14286 | 2
14259 | 2
14265 | 2
14277 | 2
(5 rows)

Индэкс мог побиться как-то. Впрочем, я бы сначала на запрос посмотрел -- с полным определением таблицы. Мало ли, что вы там устроили.

Экспортировал запрос построения этой таблицы. Ничего необычного не нашел. Может быть где-то в переменных есть проблема, которой я не вижу? SET statement_timeout = 0; SET lock_timeout = 0; SET idle_in_transaction_session_timeout = 0; SET client_encoding = 'UTF8'; SET standard_conforming_strings = on; SELECT pg_catalog.set_config('search_path', '', false); SET check_function_bodies = false; SET xmloption = content; SET client_min_messages = warning; SET row_security = off; SET default_tablespace = ''; SET default_with_oids = false;

Можэт и есть, но это куда менее вероятно. Я не спрашывал у вас про запрос построения этой таблицы -- это пока нерелевантно. Я спрашывал про запрос, которым вы те количества получали.

А запрос, которым это было получено, покажете? А то мало ли...

Да вот пытаюсь узнать у разработчика. Утверждает что обычный insert без явного указания code (берется их seq)

В четвёртый раз поясняем: надо не какие там insert были (чёрт с ними, тем более что результат должэн быть одинаковым при любых инсертах) -- а каким запросом вы эти строчки с количеством получили.

просьбу показать "запрос с полным определением таблицы" я понял изначально как DDL таблицы. неверно понял что нужно было показать

Наврерное все таки в запросе там проблема. Спасибо. Натолкнули на мысль ) Хотя, наверное всё же нет. Клиент работает с данными и сложно понять, что происходит. Договорюсь с клиентом, чтобы не трогал пока что данные, если это возможно. А то у меня один и тот же запрос выполняется с разными результатами

Денис Бондарь
Вот сейчас я понимаю, что вообще ничего не понимаю

Интересно, какая (сходу не видно)? И да, можно показывать тексты запросов с помощью... текста?! ;)

select code, count(*) from userside3.pbl_base group by code order by count(*) desc limit 20;

Выполните в сессии следующее: EXPLAIN (ANALYZE) select * from userside3.pbl_base WHERE code = <любой из задублированных кодов>; SET enable_indexscan = off; SET enable_bitmapscan = off; EXPLAIN (ANALYZE) select * from userside3.pbl_base WHERE code = <любой из задублированных кодов>; покажите результаты.

ПРоблема в том, что эти "двойники" периодически исчезают, а потом снова появляются. Почему это происходит — я не знаю. С клиентом связь через тикет-систему и она не быстрая. Клиент увидит сообщение и ответит на него не моментально. Дождусь когда снова будет по 2 штуки — сделаю

А в чём проблема найти их прямо сейчас, показанным Вами запросом?! Или это были совсем не актуальные данные? Вы понимаете, в чём дело... если это настоящие двойники — у Вас кластер баз битый, и тут нужно не ждать чего-то, а спасать его, пока он совсем не накрылся (если есть backup, проще может быть заменить "железо" и восстановить из него).

В запросе с count() задваиваются постоянно одни и те же code но если выбирать строку с этим code — то она одна всегда, даже когад count() говорит что две причем count() говорит что две только тогда, когда явыбираю без условий по code стоит добавить условие с code = ... сразу же count() говорит что строка одна если выбирать строку (а не count) то она всегда одна сейчас выполню ваши запросы

да скиньте вы уже запросы, который раз вас просят

сейчас у меня по моему запросу с count() нет ни одного задвоенного code но периодически они появляются при выборке с count() но при выборке строки (а не count) строка всегда одна

сейчас в базе нет задвоеных code в чем смысл их выполнения? сделать то не проблема, только они сейчас вряд ли что-то покажут

да какая разница, есть или нет вы ЗАПРОС покажите

Когда будут, конечно. Но, опять-таки, если Вы всё правильно показали — такого должно не быть. Кстати... а \d+ userside3.pbl_base можете показать?

я его привел в самом первом сообщении

Денис Бондарь
Вот сейчас я понимаю, что вообще ничего не понимаю

Одно indexscan, другое seqscan небось. Вообще, текст гораздо лучшэ копировать текстом -- но да, на первый взгляд запросы выглядят правильными, так что это похожэ навернулся индэкс. Сочувствую, да. Просто rebuild скорее всего не пройдёт, по причине неконсистентности данных. Постарайтесь как-то удалить лишние, потом rebuild.

https://pastebin.com/1Qa736bW пожалуйста. если это что-то даст — отлично но в данный момент никаких задвоений нет

Нет, не привели! Нужно целиком. И да, мне это уже начинает надоедать — это Ваша проблема или наша?! Кто-то тут обязан из Вас "клещами тянуть" информацию?

Если что-то нужно — достаточно конкретно попросить. Я не умею догадываться, увы. Сейчас дам полный вывод, если это что-то даст, в чем я не уверен.

Денис Бондарь
Вот сейчас я понимаю, что вообще ничего не понимаю

А, ещё -- советы про rebuild -- это в предположэнии, что backup у вас есть, в цэлости и сохранности. И, реально, лучшэ некоторое количество бэкапов перевести в архив -- в смысле перестать удалять. На проблемы с диском это тожэ вполне похожэ, да. Хотя могут быть и другие причины, и есть шанс, что мы никогда про них не узнаем.

Ну конечно же, "нет", ага. Сравните: -> Index Only Scan using pbl_base_pkey on pbl_base (cost=0.29..8.31 rows=1 width=0) (actual time=0.077..0.081 rows=1 loops=1) и -> Seq Scan on pbl_base (cost=0.00..6215.06 rows=1 width=0) (actual time=2.046..15.742 rows=2 loops=1) Как Вы думаете, что означает подчёркнутое? Выполните в той же сессии (или ещё раз выполните эти SET-ы в новой) просто select count(*) from userside3.pbl_base where code = 14282; — какой результат?

Пожалуйста https://pastebin.com/kurC9Nqf

> Я не умею догадываться, увы. Так может, если Вы понятия не имеете в чём проблема — стоит прекратить догадываться, какая информация имеет отношение к делу, а какая нет? ;) Нет, ну правда — если кто-то это знает, он и проблему обычно способен найти и решить.

userside=> select count(*) from userside3.pbl_base where code = 14282; count ------- 1 (1 row) userside=> SET enable_indexscan = off; SET userside=> SET enable_bitmapscan = off; SET userside=> select count(*) from userside3.pbl_base where code = 14282; count ------- 2 (1 row)

Да, битая база. :( Рекомендации — см. выше. Ищите причины (скорее всего — диск или настройки OS).

Спасибо.

Типичные другие проблемы, например -- это неправильно выключенный рейд с батарейкой (и кэшэм записи) или прерванное на лету восстановление из бэкапа через tar или грохнутый по недоразумению WAL. В общем, есть не один способ случайно попротить базу под линуксом.

Ясно спасибо. Передам это клиенту. Надеюсь, ему поможет ваше описание возможных причин разобраться, что произошло. Большое всем откликнувшимся спасибо!

скажите, под tar архивом вы имели ввиду восстановление из dump или из sql-скрипта?

Из pg_basebackup. Нет, любыми видами pg_dump такого не достичь.

ясно