|
idle in transaction (aborted) держит ли снимок БД ?
|
|||
---|---|---|---|
#18+
Коллеги, бодрый день. Из описания непонятно: idle in transaction: серверный процесс находится внутри транзакции, но в настоящее время не выполняет никакой запрос. idle in transaction (aborted): Это состояние подобно idle in transaction, за исключением того, что один из операторов в транзакции вызывал ошибку. idle in transaction (aborted) держит ли снимок БД ? ... |
|||
:
Нравится:
Не нравится:
|
|||
02.08.2018, 13:38 |
|
idle in transaction (aborted) держит ли снимок БД ?
|
|||
---|---|---|---|
#18+
Синий Слон, Для начала нужно определиться с уровнем изоляции этой транзакции. Для READ COMMITTED, что по умолчанию, снимок создается на момент начала каждого оператора и действует до окончания работы оператора, поэтому и для idle in transaction, и для idle in transaction (aborted) снимок уже "закончился". Что касается REPEATABLE READ и SERIALIZABLE, для которых снимок создается на момент начала первого оператора транзакции, то здесь постгрес понимает, что для транзакции с idle in transaction (aborted) снимок уже не понадобится, а для idle in transaction снимок нужно держать. ... |
|||
:
Нравится:
Не нравится:
|
|||
02.08.2018, 14:41 |
|
idle in transaction (aborted) держит ли снимок БД ?
|
|||
---|---|---|---|
#18+
Павел ЛузановСиний Слон, Для начала нужно определиться с уровнем изоляции этой транзакции. Для READ COMMITTED, что по умолчанию, снимок создается на момент начала каждого оператора и действует до окончания работы оператора, поэтому и для idle in transaction, и для idle in transaction (aborted) снимок уже "закончился". Что касается REPEATABLE READ и SERIALIZABLE, для которых снимок создается на момент начала первого оператора транзакции, то здесь постгрес понимает, что для транзакции с idle in transaction (aborted) снимок уже не понадобится, а для idle in transaction снимок нужно держать. Я сильно подозреваю вопрос был влияет ли idle in transaction (aborted) на bloat так же как просто idle in transaction а не про собственно snapshot. Или про держит ли idle in transaction (aborted) AccessShareLock на таблицы которые были в транзакции (влияние на внесение alters). Я бы предположил да на оба вопроса но не уверен на 100%. -- Maxim Boguk лучшая поддержка PostgreSQL: dataegret.ru ... |
|||
:
Нравится:
Не нравится:
|
|||
02.08.2018, 14:51 |
|
idle in transaction (aborted) держит ли снимок БД ?
|
|||
---|---|---|---|
#18+
Maxim BogukЯ сильно подозреваю вопрос был влияет ли idle in transaction (aborted) на bloat так же как просто idle in transaction а не про собственно snapshot. Я под "держанием" снимка понял, что vacuum не должен вычищать версии строк удаленных в другой транзакции. Вроде это как раз про bloat. В таком случае, дело обстоит ровно так, как написал выше. Maxim BogukИли про держит ли idle in transaction (aborted) AccessShareLock на таблицы которые были в транзакции (влияние на внесение alters). Я бы предположил да на оба вопроса но не уверен на 100%. А вот о таком раскладе не подумал и перепроверил. Для транзакции в статусе idle in transaction (aborted) блокировки в pg_locks (типа AccessShareLock) удаляются. Верно для любых уровней изоляции. Это и логично, ведь такая транзакция всё равно больше ничего сделать не сможет. ... |
|||
:
Нравится:
Не нравится:
|
|||
02.08.2018, 15:10 |
|
idle in transaction (aborted) держит ли снимок БД ?
|
|||
---|---|---|---|
#18+
В общем на исходный вопрос я бы ответил, что idle in transaction (aborted) ничего не держит. Но хотелось бы прояснить вот какой момент. Часто слышу, что просто idle in transaction влияет на bloat, вот и Максим на это намекает: Maxim BogukЯ сильно подозреваю вопрос был влияет ли idle in transaction (aborted) на bloat так же как просто idle in transaction ... Хотелось бы разобраться каким именно образом. Дело в том, что простые эксперименты этого влияния не показывают (при условии что транзакции по умолчанию в READ COMMITTED). Первая сессия: Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11.
Вторая сессия: Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19.
Как видно, ничего не мешает вакууму почистить удаленную версию строки, хотя первая транзакция в idle in transaction. Распухание не происходит. Подозреваю, что жизнь богаче, но где подвох? ... |
|||
:
Нравится:
Не нравится:
|
|||
02.08.2018, 16:02 |
|
idle in transaction (aborted) держит ли снимок БД ?
|
|||
---|---|---|---|
#18+
Павел Лузанов, Предположу, что дело именно уровне изоляции. Уровень read commited позволяет удалить старую версию строки (в т.ч. в состоянии idle in transaction), repeatable read - нет ... |
|||
:
Нравится:
Не нравится:
|
|||
06.08.2018, 10:13 |
|
idle in transaction (aborted) держит ли снимок БД ?
|
|||
---|---|---|---|
#18+
gav21, Я пришел к такому выводу. Долговисящие транзакции в статусе idle in transaction это, конечно же, зло: 1. Нельзя получить эксклюзивные блокировки на таблицы (например для ALTER TABLE), к которым выполнялись запросы, т.к. висящие транзакции удерживают блокировки AccessShareLock. 2. Может остановиться заморозка транзакций. 3. Если висящая транзакция уже изменяла/удаляла строки, то vacuum не сможет почистить старые версии этих строк. 4. Если статус idle in transaction у транзакций REPEATABLE READ, SERIALIZABLE - вообще беда, vacuum не будет вычищать версии строк видимые в этих транзакциях, а это распухание таблиц и индексов. Да и вообще, остановка работы в середине транзакции - странная логика работы приложения с БД, есть повод задуматься о переписывании. Поэтому параметр idle_in_transaction_session_timeout придуман в 9.6 не зря. Тем не менее, в общем случае нельзя утверждать, что транзакции висящие в статусе idle in transaction приводят к распуханию таблиц. ... |
|||
:
Нравится:
Не нравится:
|
|||
06.08.2018, 16:10 |
|
idle in transaction (aborted) держит ли снимок БД ?
|
|||
---|---|---|---|
#18+
Павел ЛузановВ общем на исходный вопрос я бы ответил, что idle in transaction (aborted) ничего не держит. Но хотелось бы прояснить вот какой момент. Часто слышу, что просто idle in transaction влияет на bloat, вот и Максим на это намекает: Maxim BogukЯ сильно подозреваю вопрос был влияет ли idle in transaction (aborted) на bloat так же как просто idle in transaction ... Хотелось бы разобраться каким именно образом. Дело в том, что простые эксперименты этого влияния не показывают (при условии что транзакции по умолчанию в READ COMMITTED). Первая сессия: Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11.
Вторая сессия: Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19.
Как видно, ничего не мешает вакууму почистить удаленную версию строки, хотя первая транзакция в idle in transaction. Распухание не происходит. Подозреваю, что жизнь богаче, но где подвох? Хороший пример, однако, в большинстве случаев он не верный :( Если сессия что-то меняет, то вакум уже не вычещает... Если вставить до select *, pg_backend_pid() from t; в вашем примере это: Код: sql 1.
То получаем: ИНФОРМАЦИЯ: очистка "public.t" ИНФОРМАЦИЯ: "t": найдено удаляемых версий строк: 0, неудаляемых - 2, обработано страниц: 1, всего страниц: 1 DETAIL: В данный момент нельзя удалить версий "мёртвых" строк: 1. Неиспользованных указателей: 0. Полностью пустых страниц: 0. CPU 0.00s/0.00u sec elapsed 0.00 sec. Запрос успешно выполнен без возвращаемых данных за 79 мс. ... |
|||
:
Нравится:
Не нравится:
|
|||
08.08.2018, 17:14 |
|
idle in transaction (aborted) держит ли снимок БД ?
|
|||
---|---|---|---|
#18+
Или я ошибаюсь?... ... |
|||
:
Нравится:
Не нравится:
|
|||
08.08.2018, 17:22 |
|
idle in transaction (aborted) держит ли снимок БД ?
|
|||
---|---|---|---|
#18+
А aborted так и не получилось сделать, открываю транзакцию: begin isolation level read committed; делаю синтаксическую ошибку: selectw и состояние коннекта превращается в idle. ... |
|||
:
Нравится:
Не нравится:
|
|||
08.08.2018, 17:31 |
|
idle in transaction (aborted) держит ли снимок БД ?
|
|||
---|---|---|---|
#18+
Синий СлонХороший пример, однако, в большинстве случаев он не верный :( Если сессия что-то меняет, то вакум уже не вычещает... Пока транзакция не закончена, можно сделать rollback, поэтому ничего вычищать нельзя. Это вроде очевидно. Про статус транзакции. Первая сессия: Код: sql 1. 2. 3. 4. 5. 6.
Вторая сессия: Код: sql 1. 2. 3. 4.
Первая сессия: Код: sql 1. 2. 3. 4.
Вторая сессия: Код: sql 1. 2. 3. 4.
... |
|||
:
Нравится:
Не нравится:
|
|||
22.08.2018, 12:31 |
|
idle in transaction (aborted) держит ли снимок БД ?
|
|||
---|---|---|---|
#18+
Павел Лузановgav21, Я пришел к такому выводу. Долговисящие транзакции в статусе idle in transaction это, конечно же, зло: 1. Нельзя получить эксклюзивные блокировки на таблицы (например для ALTER TABLE), к которым выполнялись запросы, т.к. висящие транзакции удерживают блокировки AccessShareLock. 2. Может остановиться заморозка транзакций. 3. Если висящая транзакция уже изменяла/удаляла строки, то vacuum не сможет почистить старые версии этих строк. 4. Если статус idle in transaction у транзакций REPEATABLE READ, SERIALIZABLE - вообще беда, vacuum не будет вычищать версии строк видимые в этих транзакциях, а это распухание таблиц и индексов. Да и вообще, остановка работы в середине транзакции - странная логика работы приложения с БД, есть повод задуматься о переписывании. Поэтому параметр idle_in_transaction_session_timeout придуман в 9.6 не зря. Тем не менее, в общем случае нельзя утверждать, что транзакции висящие в статусе idle in transaction приводят к распуханию таблиц. Павел, изучая это видео ... |
|||
:
Нравится:
Не нравится:
|
|||
11.09.2018, 08:53 |
|
idle in transaction (aborted) держит ли снимок БД ?
|
|||
---|---|---|---|
#18+
gav21, Вот теперь всё встало на свои места, спасибо! Действительно если первая транзакция получила номер (что-то изменяла: DML или DDL неважно), то она будет мешать очистке vacuum. Приведенный пример это отлично иллюстрирует. И хотя для транзакции в первой сессии удаленные версии строк таблицы vt не нужны, тем не менее именно она мешает вакууму. Чуток переделал пример, чтобы номер транзакции был виден. Первая сессия: Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8.
Вторая сессия: Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10.
... |
|||
:
Нравится:
Не нравится:
|
|||
11.09.2018, 17:50 |
|
|
start [/forum/topic.php?fid=53&tid=1995595]: |
0ms |
get settings: |
11ms |
get forum list: |
13ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
28ms |
get topic data: |
11ms |
get forum data: |
2ms |
get page messages: |
48ms |
get tp. blocked users: |
1ms |
others: | 275ms |
total: | 395ms |
0 / 0 |