Re: Delete from locking ordering differences

Поиск
Список
Период
Сортировка
От Rob Sargent
Тема Re: Delete from locking ordering differences
Дата
Msg-id 7b30c39f-2d36-e540-7494-c41b7e8b7179@gmail.com
обсуждение исходный текст
Ответ на Delete from locking ordering differences  (Peter Hendriks <peter@mindloops.nl>)
Список pgsql-sql
On 9/23/22 01:31, Peter Hendriks wrote:
We are wondering if anyone can explain the difference we are having in production with the following queries:

DELETE FROM store
WHERE id IN (
  SELECT id FROM store 
  FOR UPDATE SKIP LOCKED 
  ORDER BY ID
  LIMIT 1000
)
RETURNING id, payload

This query is sometimes executed with high concurrency, and then can hang indefinitely, we assume because of a locking problem that postgresql is not detecting as a deadlock.

This alternative query does not have the hanging problem:

WITH store_ids AS (
  SELECT id FROM store 
  FOR UPDATE SKIP LOCKED 
  ORDER BY ID
  LIMIT 1000
)
DELETE FROM store s
USING store_ids si 
WHERE s.id = si.id
RETURNING s.id, s.payload

Can anyone explain why the first query is expected to fail (hang), and the second query does not have this problem? We would be interested in more understanding on this. Thanks! 

The "optimizatin fence" nature of CTEs appears to be a win in this case.  Why the "order by"?  I assume these are down within a transaction?

В списке pgsql-sql по дате отправления:

Предыдущее
От: Peter Hendriks
Дата:
Сообщение: Delete from locking ordering differences
Следующее
От: Peter Hendriks
Дата:
Сообщение: Re: Delete from locking ordering differences