Идентификатор последней вставленной строки в PostgreSQL

#postgresql #lastinsertid

#postgresql #lastinsertid

Вопрос:

Я использую базу данных postgresql. И предыдущие таблицы, которые созданы моими старшими, и в них не используется концепция последовательности, они добавили данные вручную. Теперь мне нужно вставить данные в мое Java-приложение. для этого мне нужен идентификатор последней вставленной строки. У меня нет разрешения на добавление последовательности.
пожалуйста, кто-нибудь, помогите мне.
заранее спасибо…

Комментарии:

1. Любое решение, которое не использует последовательности, либо не масштабируемо, либо небезопасно при выполнении нескольких транзакций

2. Ищите новую работу, когда сможете. «Старшим» пользователям базы данных следует знать лучше.

3. @Andrew Lazarus, «старший» означает предыдущего разработчика. Не администратор и т.д..

Ответ №1:

В идеале вам следует запросить разрешение на создание необходимых последовательностей.

Если это невозможно по какой-либо бюрократической причине, вам может удастся обойти проблемы параллелизма, используя рекомендательные блокировки. Псевдокод:

 loop
select id as last_id, pg_try_advisory_lock('yourtable'::regclass, id) as locked
from yourtable
order by id desc limit 1

 if not locked then sleep .01 else exit end if
end loop

new_id = last_id   1
insert...

select pg_advisory_unlock('yourtable'::regclass, last_id)
  

Комментарии:

1. Я бы придерживался фактических блокировок для всей таблицы. Без последовательностей это единственный способ убедиться, что вы все поняли правильно. Но да, если идиоты-боссы не позволят OP добавлять последовательности, их нужно заменить комнатными растениями, поскольку, по крайней мере, комнатное растение выделяет кислород и делает что-то полезное

2. @peufeu: Я не совсем уверен… Консультативная блокировка должна гарантировать, что он всегда имеет дело с последним идентификатором, поскольку никакие две транзакции не могут получить его одновременно для одной и той же строки, а режим ожидания должен гарантировать, что параллельные транзакции найдут новый last_id, если им придется повторить попытку. Тем не менее, ключевыми словами здесь являются might и should , а не will . Автор вопроса действительно должен создать последовательность. 😉

3. Ноно, безумие не в твоем решении, а в его боссе!

4. Проблема с консультативными блокировками, о которой я беспокоюсь, заключается в состоянии гонки и обработке ошибок. Если они не соответствуют требованиям, вы получаете дублирующие идентификаторы. Блокировка таблицы кажется экстремальной, но это происходит всего на долю секунды, а затем она исчезает. Пока нет длительных выборок, чтобы он застрял позади, все в порядке. И давайте посмотрим правде в глаза, ребята, которые сказали «нет последовательностей», не заслуживают такого количества кода, устранения неполадок и контроля качества, чтобы убедиться, что работает что-то более причудливое, чем блокировки таблиц. Они нарисовали себя в углу…