Re: ALTER TABLE esperando por nada

From: Sebastian Webber <sebastian(at)swebber(dot)me>
To: Hortencia Campos <hortenciadsc(at)gmail(dot)com>
Cc: Flavio Henrique Araque Gurgel <fhagur(at)gmail(dot)com>, Ranier Vilela <ranier(dot)vf(at)gmail(dot)com>, Comunidade PostgreSQL Brasileira <pgsql-pt-geral(at)lists(dot)postgresql(dot)org>
Subject: Re: ALTER TABLE esperando por nada
Date: 2020-12-06 11:14:34
Message-ID: CACV2tSzY=yY9GaENAhjsjKmgyQCqjXwM6k4N56kee3_EY5Cseg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-pt-geral

Em dom., 6 de dez. de 2020 às 00:54, Hortencia Campos <
hortenciadsc(at)gmail(dot)com> escreveu:

> <corte>
> Oi Flavio,
>
> ele mostra o wait_event = relation.
>
> Mas eu acho que já descobri o que está acontecendo. O problema se repetiu
> ao tentar excluir uma trigger de outra tabela.
>

na view pg_locks tu vai pegar informação de quem tá fazendo o lock. abre
uma sessão separada do psql enquanto seu alter table roda e testa o que tá
errado. essa query[4] pode ajudar.

veja meu exemplo na sessão 1:

❯ psql
psql (13.1 (Ubuntu 13.1-1.pgdg20.04+1))
Type "help" for help.

seba=# create table foo (id serial primary key, name text);
CREATE TABLE
seba=# insert into foo (name) select 'foo factory #' ||
generate_series(1,10000);
INSERT 0 10000
seba=# begin;
BEGIN
seba=*# select * from foo order by random() limit 10;
id | name
------+-------------------
7088 | foo factory #7088
7589 | foo factory #7589
4986 | foo factory #4986
767 | foo factory #767
9824 | foo factory #9824
5158 | foo factory #5158
4238 | foo factory #4238
699 | foo factory #699
8007 | foo factory #8007
1668 | foo factory #1668
(10 rows)

Na sessão 2:

❯ psql
psql (13.1 (Ubuntu 13.1-1.pgdg20.04+1))
Type "help" for help.

seba=# alter table foo add column some_date timestamp;

agora os locks (capturados na sessão 2):

❯ psql -x
psql (13.1 (Ubuntu 13.1-1.pgdg20.04+1))
Type "help" for help.

seba=# SELECT blocked_locks.pid AS blocked_pid,
blocked_activity.usename AS blocked_user,
blocking_locks.pid AS blocking_pid,
blocking_activity.usename AS blocking_user,
blocked_activity.query AS blocked_statement,
blocking_activity.query AS current_statement_in_blocking_process
FROM pg_catalog.pg_locks blocked_locks
JOIN pg_catalog.pg_stat_activity blocked_activity ON
blocked_activity.pid = blocked_locks.pid
JOIN pg_catalog.pg_locks blocking_locks
ON blocking_locks.locktype = blocked_locks.locktype
AND blocking_locks.database IS NOT DISTINCT FROM
blocked_locks.database
AND blocking_locks.relation IS NOT DISTINCT FROM
blocked_locks.relation
AND blocking_locks.page IS NOT DISTINCT FROM blocked_locks.page
AND blocking_locks.tuple IS NOT DISTINCT FROM blocked_locks.tuple
AND blocking_locks.virtualxid IS NOT DISTINCT FROM
blocked_locks.virtualxid
AND blocking_locks.transactionid IS NOT DISTINCT FROM
blocked_locks.transactionid
AND blocking_locks.classid IS NOT DISTINCT FROM
blocked_locks.classid
AND blocking_locks.objid IS NOT DISTINCT FROM blocked_locks.objid
AND blocking_locks.objsubid IS NOT DISTINCT FROM
blocked_locks.objsubid
AND blocking_locks.pid != blocked_locks.pid
JOIN pg_catalog.pg_stat_activity blocking_activity ON
blocking_activity.pid = blocking_locks.pid
WHERE NOT blocked_locks.granted;
-[ RECORD 1
]-------------------------+------------------------------------------------
blocked_pid | 26511
blocked_user | seba
blocking_pid | 26147
blocking_user | seba
blocked_statement | alter table foo add column
some_date timestamp;
current_statement_in_blocking_process | select * from foo order by random()
limit 10;

-- select relation::regclass, * from pg_locks;

[image: image.png]

Outra coisa que pode ajudar é tu habilitar o log de todas as queries com os
parametros log_statements[1], log_min_duration_statement[2] ou o
log_lock_waits[3].

>
> Esse banco foi criado a partir de um standby que não recebeu todos os
> archives, então eu acho ele abriu inconsistente.
>

Nos logs do banco vai ter alguma referência a problema, se for o caso.

> Ai vários objetos parecem está corrompidos.
>

Se os dados estão de fato corrompidos, vai dar erro ao ler a tabela, é o
caso ? um simples select pode dar uma idéia. Pra o teu caso, parece mais
uma questão de lock.

> Alguém sabe se tem como eu confirmar isso?
>
> De qualquer forma, obrigada a todos pela ajuda!
>

Ref:

1. https://postgresqlco.nf/en/doc/param/log_statement/10/
2. https://postgresqlco.nf/en/doc/param/log_min_duration_statement/10/
3. https://postgresqlco.nf/en/doc/param/log_lock_waits/10/
4.
https://wiki.postgresql.org/wiki/Lock_Monitoring#.D0.A1ombination_of_blocked_and_blocking_activity

--
Sebastian Webber
Chegou a ver o meu blog <http://swebber.me>? Dá uma olhada no que eu ando
aprontando: http://swebber.me

In response to

Browse pgsql-pt-geral by date

  From Date Subject
Next Message Hortencia Campos 2020-12-07 15:10:14 Re: Muita geração de log - Postgres 10
Previous Message Hortencia Campos 2020-12-06 03:53:52 Re: ALTER TABLE esperando por nada