Моя функція new_customer
викликається веб-додатком кілька разів на секунду (але лише один раз за сеанс). Найперше, що він робить - це заблокувати customer
таблицю (зробити "вставку, якщо її немає" - простий варіант а upsert
).
Я розумію документи , що інші дзвінки new_customer
повинні просто стояти в черзі, поки всі попередні дзвінки не закінчаться:
LOCK TABLE отримує блокування на рівні таблиці, чекаючи, якщо це необхідно, для звільнення будь-яких конфліктних замків.
Чому іноді замість цього відбувається тупикова ситуація?
визначення:
create function new_customer(secret bytea) returns integer language sql
security definer set search_path = postgres,pg_temp as $$
lock customer in exclusive mode;
--
with w as ( insert into customer(customer_secret,customer_read_secret)
select secret,decode(md5(encode(secret, 'hex')),'hex')
where not exists(select * from customer where customer_secret=secret)
returning customer_id )
insert into collection(customer_id) select customer_id from w;
--
select customer_id from customer where customer_secret=secret;
$$;
помилка з журналу:
2015-07-28 08:02:58 BST ДЕТАЛІ: Процес 12380 очікує на ExclusiveLock щодо відношення 16438 бази даних 12141; заблокований процесом 12379. Процес 12379 очікує на ExclusiveLock щодо відношення 16438 бази даних 12141; заблокований процесом 12380. Процес 12380: виберіть new_customer (декодування ($ 1 :: текст, «шістнадцятковий»)) Процес 12379: виберіть new_customer (декодування ($ 1 :: текст, "шістнадцятковий")) 2015-07-28 08:02:58 BST Підказка: Перегляньте журнал сервера, щоб отримати детальну інформацію про запити. 2015-07-28 08:02:58 BST CONTEXT: SQL-функція "new_customer" 1 2015-07-28 08:02:58 BST ЗАЯВКА: виберіть new_customer (декодування ($ 1 :: текст, "шістнадцятковий"))
відношення:
postgres=# select relname from pg_class where oid=16438;
┌──────────┐
│ relname │
├──────────┤
│ customer │
└──────────┘
редагувати:
Мені вдалося отримати простий тестовий випадок, який можна відтворити. Для мене це схоже на помилку через якийсь стан перегонів.
схема:
create table test( id serial primary key, val text );
create function f_test(v text) returns integer language sql security definer set search_path = postgres,pg_temp as $$
lock test in exclusive mode;
insert into test(val) select v where not exists(select * from test where val=v);
select id from test where val=v;
$$;
скрипт bash запускається одночасно у двох сеансах bash:
for i in {1..1000}; do psql postgres postgres -c "select f_test('blah')"; done
журнал помилок (як правило, декілька тупиків за 1000 викликів):
2015-07-28 16:46:19 BST ERROR: deadlock detected
2015-07-28 16:46:19 BST DETAIL: Process 9394 waits for ExclusiveLock on relation 65605 of database 12141; blocked by process 9393.
Process 9393 waits for ExclusiveLock on relation 65605 of database 12141; blocked by process 9394.
Process 9394: select f_test('blah')
Process 9393: select f_test('blah')
2015-07-28 16:46:19 BST HINT: See server log for query details.
2015-07-28 16:46:19 BST CONTEXT: SQL function "f_test" statement 1
2015-07-28 16:46:19 BST STATEMENT: select f_test('blah')
редагувати 2:
@ypercube запропонував варіант із lock table
зовнішньою функцією:
for i in {1..1000}; do psql postgres postgres -c "begin; lock test in exclusive mode; select f_test('blah'); end"; done
що цікаво, це усуває тупики.
customer
використовується таким чином, щоб схопити слабший замок? Тоді це може бути проблема оновлення блокування.