Красное смещение или усечение стола очень медленно

Ответ 1

Redshift имеет очень быстрый ввод-вывод, поэтому для любого типа кластера или его размера требуется меньше 1 секунды. Как сказал diemacht, проблема вызвана тем, что у вас есть другое соединение с открытой транзакцией.

У меня была аналогичная проблема: авария на клиенте оставила транзакцию открытой, но недоступной. В таблице STV_LOCKS не обнаружено блокировки db: (используя select table_id, last_update, lock_owner, lock_owner_pid from stv_locks;)

Кроме того, запрос еще не выполнялся: (отмечено с помощью: select pid, trim(user_name), starttime, query , substring(query,1,20), status from stv_recents where status='Running';)

Таким образом, решение заключалось в перечислении пользовательских сеансов: SELECT * FROM STV_SESSIONS И затем убейте его, используя: SELECT pg_terminate_backend(pid)

Или версия KILL'EM ALL:

SELECT pg_terminate_backend(process) FROM STV_SESSIONS where user_name='user_name' and process != pg_backend_pid();

Обратите внимание, что CANCEL {pid} не работает! (запрос был отменен, но транзакция все еще была открыта и заблокирована).

Ответ 2

По моему опыту, как говорит @Gerardo Grignoli, блокировки не отображаются в таблице stv_locks, но они отображаются в pg_locks. В зависимости от вашей среды может быть неприемлемо убить произвольный длительный сеанс, указанный в stv_sessions. Я считаю таблицу pg_locks очень надежной для обнаружения этого типа блокировки:

select * from pg_locks where relation = (select oid from pg_class where relname = 'the_table')
select pg_cancel_backend(pid)

Как правило, проблема заключается в блокировке ACCESS EXCLUSIVE, которая блокирует таблицу. Итак, если указано много замков, найдите и убейте ACCESS EXCLUSIVE один.

Ответ 3

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

Например, если у вас есть 2 оболочки с красной школой, вы не сможете отбросить таблицу из первой оболочки, участвующей в открытой транзакции во второй оболочке.

После того, как я совершил/откат во втором окне, truncate работал отлично.

Надеюсь, что это помогло.

Ответ 4

IMO AccessShareLock на таблицах также заставляет команды DDL застревать.

Запустите этот запрос, чтобы выяснить, какие значения AccessShareLock

select
  current_time,
  c.relname,
  l.database,
  l.transaction,
  l.pid,
  a.usename,
  l.mode,
  l.granted
from pg_locks l
join pg_catalog.pg_class c ON c.oid = l.relation
join pg_catalog.pg_stat_activity a ON a.procpid = l.pid
where l.pid <> pg_backend_pid();

Убейте процессы, используя select pg_terminate_backend(<pid>);

Убедитесь, что все ваши приложения только для чтения закрываются и освобождают все подключения и, следовательно, эти блокировки!