Откуда появляются отрицательные значения индекса первичного ключа PostgreSQL?

Question

[Олег Безверхий]

Появился следующий вопрос в плане работы с PostgreSQL через Entity Framework.

Имеется следующая таблица:

CREATE TABLE "TankContentStateHistory" (
"TankContentStateHistoryId" integer NOT NULL SET DEFAULT nextval('"TankContentStateHistory_TankContentStateHistoryId_seq"'::regclass),
"AverageTemperature" double precision NOT NULL,
...
"GTVolume" double precision DEFAULT 0.0 NOT NULL);

TankContentStateHistoryId берет свои значения из перечисления TankContentStateHistory_TankContentStateHistoryId_seq:

CREATE SEQUENCE "TankContentStateHistory_TankContentStateHistoryId_seq"
START WITH 1
INCREMENT BY 1
NO MINVALUE
NO MAXVALUE
CACHE 1;

Значения должны быть все время положительными, но в последнее время стали появляться моменты, когда первичный ключ становится с отрицательным значением и откуда оно берется - не понятно. Логи PostgreSQL ясности не вносят:

2021-09-19 00:45:58 MSK ОШИБКА:  повторяющееся значение ключа нарушает ограничение уникальности "PK_TankContentStateHistory"
2021-09-19 00:45:58 MSK ПОДРОБНОСТИ:  Ключ "("TankContentStateHistoryId")=(-2147482602)" уже существует.
2021-09-19 00:45:58 MSK ОПЕРАТОР:  INSERT INTO "TankContentStateHistory" ("TankContentStateHistoryId", ... "GTVolume")
VALUES ($1, ..)

EntityFrameworkCore по сути дублирует тоже самое:

Microsoft.EntityFrameworkCore.DbUpdateException: An error occurred while updating the entries. See the inner exception for details. ---> Npgsql.PostgresException: 23505: повторяющееся значение ключа нарушает ограничение уникальности "PK_TankContentStateHistory"
в Npgsql.NpgsqlConnector.<>c__DisplayClass161_0.<<ReadMessage>g__ReadMessageLong|0>d.MoveNext()

Вопрос в следующем - в каком месте может возникнуть проблема? Потому что после тщетных попыток уставить значение, все следующие значения ключа идет дальше по последовательности (например, id = 2044, потом отрицательное значение id=-454635, после id=2045).

Comments

[Николай Савельев]

Переполнение int?

[Олег Безверхий]

Agent Smith, тоже была такая мысль, но Id берётся то из перечислений. Я попробую посмотреть PGAdmin'ом, когда будет повторяться такая ситуация, но во время простой работы приложения все нормально - в диагностике я вижу текущее значение перечисления и следующее значение. Сейчас число последовательности в районе 2 милиоона 230 тысяч, до максимума ещё далеко. Просто не совсем понимаю, откуда может взяться переполнение, если Id напрямую в Entity не передаётся, в последовательности ошибки не вижу тоже.

[rPman]

а можешь посмотреть, какой sql запрос при этом был? а то может EF решило сумничать и само полезло в сиквенс и где то напортачили с кодом, правда не представляю как

[Олег Безверхий]

rPman, простой insert into

[galaxy]

Олег Безверхий,

но Id берётся то из перечислений.

ну как же, вот же ваш запрос:

INSERT INTO "TankContentStateHistory" ("TankContentStateHistoryId", ... "GTVolume")
VALUES ($1, ..)

руками вставляется TankContentStateHistoryId

[rPman]

получается баг в entity framework, ковыряй исходники в отладчике (поставь прямо в брекпоинте условие на отрицательное значение) что ли, благо они открыты

Answer 1

[Station 72]

https://stackoverflow.com/questions/41732585/ef-co...

Comments

[Олег Безверхий]

Походу это тот случай, спасибо!

Answer 2

[Slava Rozhnev]

А почему бы не использовать встроеный тип serial вместо TankContentStateHistory_TankContentStateHistoryId_seq

CREATE TABLE "TankContentStateHistory" (
  "TankContentStateHistoryId" serial NOT NULL,
  "AverageTemperature" double precision NOT NULL,
  "GTVolume" double precision DEFAULT 0.0 NOT NULL
);

INSERT INTO "TankContentStateHistory" ("AverageTemperature", "GTVolume") VALUES (10, 20);

SELECT * FROM "TankContentStateHistory";

PostgreSQL fiddle

Comments

[Олег Безверхий]

Да я бы так и сделал, но приложение не наше (мы конечный пользователь) - просто выясняем по логам, что может быть, чтобы помочь разработчику устранить проблемы.

Answer 3

[King Leon]

Отрицательные значения признак того, что у Вас счетчик "на второй круг пошел".
Поменяйте на BigInt.

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