gav21Привет.
Сегодня была интересная ситуация. Произошло чудо и автовакуум вычищая таблицу смог вернуть в ОС порядка 40ГБ места
2018-12-14 10:08:27 MSK 8639 LOG: automatic vacuum of table "t": index scans: 1
pages: 5119808 removed, 24913696 remain, 0 skipped due to pins
tuples: 890717 removed, 118726447 remain, 2668 are dead but not yet removable
buffer usage: 9195650 hits, 26052950 misses, 3750910 dirtied
avg read rate: 12.556 MB/s, avg write rate: 1.808 MB/s
system usage: CPU 493.58s/1823.96u sec elapsed 16210.80 sec
К этому серверу есть 2 стэндбая с каскадной конфигурацией.
Один из стэндбаев используется для аналитики, и все запросы на нем висели в блокировке пока работал вышеуказанный автовакум.
Блокировали запросы друг друга. Не отрабатывал даже explain.

Как только вакум расправился с таблицей на мастере, запросы на реплике рассосались.
При всем этом на мастере проблем с запросами к этой таблице не было.
Что это было? Некая особенность репликации на этой фазе вакума?
ПГ 9.5

Да. Чтобы autovacuum мог обрезать файл таблицы ему надо полный лок на таблицу взять.
Который потом будет на репликах проигран. А там он может с каким то уже идущим запросом законфликтовать.
Т.е. вот работает запрос на реплике с этой таблицей... он держит AccessShare lock на нее.
Пришел replay с AccessExclusive локом, поскольку replay этот Lock взять не может пока AccessShare не освободят - он становится в ожидание.... а все остальные запросы к этой таблице - на него уже залочатся.

На мастере такой проблемы нет потому что если бы во время autovacuum какой то запрос с таблицей этой работал - autovacuum не смог бы освободить место потому что не смог бы лок взять.

--
Maxim Boguk
лучшая поддержка PostgreSQL: dataegret.ru