powered by simpleCommunicator - 2.0.53     © 2025 Programmizd 02
Форумы / PostgreSQL [игнор отключен] [закрыт для гостей] / idle in transaction (aborted) держит ли снимок БД ?
13 сообщений из 13, страница 1 из 1
idle in transaction (aborted) держит ли снимок БД ?
    #39682561
Синий Слон
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Коллеги, бодрый день.

Из описания непонятно:

idle in transaction: серверный процесс находится внутри транзакции, но в настоящее время не выполняет никакой запрос.

idle in transaction (aborted): Это состояние подобно idle in transaction, за исключением того, что один из операторов в транзакции вызывал ошибку.




idle in transaction (aborted) держит ли снимок БД ?
...
Рейтинг: 0 / 0
idle in transaction (aborted) держит ли снимок БД ?
    #39682611
Павел Лузанов
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Синий Слон,

Для начала нужно определиться с уровнем изоляции этой транзакции.
Для READ COMMITTED, что по умолчанию, снимок создается на момент начала каждого оператора и действует до окончания работы оператора, поэтому и для idle in transaction, и для idle in transaction (aborted) снимок уже "закончился".

Что касается REPEATABLE READ и SERIALIZABLE, для которых снимок создается на момент начала первого оператора транзакции, то здесь постгрес понимает, что для транзакции с idle in transaction (aborted) снимок уже не понадобится, а для idle in transaction снимок нужно держать.
...
Рейтинг: 0 / 0
idle in transaction (aborted) держит ли снимок БД ?
    #39682614
Фотография Maxim Boguk
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Павел ЛузановСиний Слон,

Для начала нужно определиться с уровнем изоляции этой транзакции.
Для 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
...
Рейтинг: 0 / 0
idle in transaction (aborted) держит ли снимок БД ?
    #39682633
Павел Лузанов
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
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) удаляются. Верно для любых уровней изоляции.
Это и логично, ведь такая транзакция всё равно больше ничего сделать не сможет.
...
Рейтинг: 0 / 0
idle in transaction (aborted) держит ли снимок БД ?
    #39682676
Павел Лузанов
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
В общем на исходный вопрос я бы ответил, что 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.
postgres=# create table t (id int);
CREATE TABLE
postgres=# insert into t values (1);
INSERT 0 1
postgres=# begin isolation level read committed;
BEGIN
postgres=# select *, pg_backend_pid() from t;
 id | pg_backend_pid 
----+----------------
  1 |           3876
(1 row)


Вторая сессия:
Код: sql
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
postgres=# select state from pg_stat_activity where pid =3876;
        state        
---------------------
 idle in transaction
(1 row)

postgres=# delete from t where id = 1;
DELETE 1
postgres=# vacuum verbose t;
INFO:  vacuuming "public.t"
INFO:  "t": removed 1 row versions in 1 pages
INFO:  "t": found 1 removable, 0 nonremovable row versions in 1 out of 1 pages
DETAIL:  0 dead row versions cannot be removed yet, oldest xmin: 122792
There were 0 unused item pointers.
Skipped 0 pages due to buffer pins, 0 frozen pages.
0 pages are entirely empty.
CPU: user: 0.00 s, system: 0.00 s, elapsed: 0.00 s.
INFO:  "t": stopping truncate due to conflicting lock request
VACUUM


Как видно, ничего не мешает вакууму почистить удаленную версию строки, хотя первая транзакция в idle in transaction.
Распухание не происходит.

Подозреваю, что жизнь богаче, но где подвох?
...
Рейтинг: 0 / 0
idle in transaction (aborted) держит ли снимок БД ?
    #39683598
gav21
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Павел Лузанов,
Предположу, что дело именно уровне изоляции.
Уровень read commited позволяет удалить старую версию строки (в т.ч. в состоянии idle in transaction), repeatable read - нет
...
Рейтинг: 0 / 0
idle in transaction (aborted) держит ли снимок БД ?
    #39683802
Павел Лузанов
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
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 приводят к распуханию таблиц.
...
Рейтинг: 0 / 0
idle in transaction (aborted) держит ли снимок БД ?
    #39684954
Синий Слон
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Павел ЛузановВ общем на исходный вопрос я бы ответил, что 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.
postgres=# create table t (id int);
CREATE TABLE
postgres=# insert into t values (1);
INSERT 0 1
postgres=# begin isolation level read committed;
BEGIN
postgres=# select *, pg_backend_pid() from t;
 id | pg_backend_pid 
----+----------------
  1 |           3876
(1 row)


Вторая сессия:
Код: sql
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
postgres=# select state from pg_stat_activity where pid =3876;
        state        
---------------------
 idle in transaction
(1 row)

postgres=# delete from t where id = 1;
DELETE 1
postgres=# vacuum verbose t;
INFO:  vacuuming "public.t"
INFO:  "t": removed 1 row versions in 1 pages
INFO:  "t": found 1 removable, 0 nonremovable row versions in 1 out of 1 pages
DETAIL:  0 dead row versions cannot be removed yet, oldest xmin: 122792
There were 0 unused item pointers.
Skipped 0 pages due to buffer pins, 0 frozen pages.
0 pages are entirely empty.
CPU: user: 0.00 s, system: 0.00 s, elapsed: 0.00 s.
INFO:  "t": stopping truncate due to conflicting lock request
VACUUM


Как видно, ничего не мешает вакууму почистить удаленную версию строки, хотя первая транзакция в idle in transaction.
Распухание не происходит.

Подозреваю, что жизнь богаче, но где подвох?


Хороший пример, однако, в большинстве случаев он не верный :(

Если сессия что-то меняет, то вакум уже не вычещает...


Если вставить до

select *, pg_backend_pid() from t;

в вашем примере это:

Код: sql
1.
insert into t values (2);




То получаем:


ИНФОРМАЦИЯ: очистка "public.t"
ИНФОРМАЦИЯ: "t": найдено удаляемых версий строк: 0, неудаляемых - 2, обработано страниц: 1, всего страниц: 1
DETAIL: В данный момент нельзя удалить версий "мёртвых" строк: 1.
Неиспользованных указателей: 0.
Полностью пустых страниц: 0.
CPU 0.00s/0.00u sec elapsed 0.00 sec.

Запрос успешно выполнен без возвращаемых данных за 79 мс.
...
Рейтинг: 0 / 0
idle in transaction (aborted) держит ли снимок БД ?
    #39684959
Синий Слон
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Или я ошибаюсь?...
...
Рейтинг: 0 / 0
idle in transaction (aborted) держит ли снимок БД ?
    #39684966
Синий Слон
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
А aborted так и не получилось сделать,

открываю транзакцию:

begin isolation level read committed;


делаю синтаксическую ошибку:


selectw



и состояние коннекта превращается в idle.
...
Рейтинг: 0 / 0
idle in transaction (aborted) держит ли снимок БД ?
    #39691666
Павел Лузанов
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Синий СлонХороший пример, однако, в большинстве случаев он не верный :(

Если сессия что-то меняет, то вакум уже не вычещает...


Пока транзакция не закончена, можно сделать rollback, поэтому ничего вычищать нельзя. Это вроде очевидно.

Про статус транзакции.

Первая сессия:
Код: sql
1.
2.
3.
4.
5.
6.
postgres=# begin;
BEGIN
postgres=# select pg_backend_pid();
 pg_backend_pid 
----------------
          11257


Вторая сессия:
Код: sql
1.
2.
3.
4.
postgres=# select state from pg_stat_activity where pid = 11257;
        state        
---------------------
 idle in transaction


Первая сессия:
Код: sql
1.
2.
3.
4.
postgres=# select1;
ERROR:  syntax error at or near "select1"
LINE 1: select1;
        ^


Вторая сессия:
Код: sql
1.
2.
3.
4.
postgres=# select state from pg_stat_activity where pid = 11257;
             state             
-------------------------------
 idle in transaction (aborted)
...
Рейтинг: 0 / 0
idle in transaction (aborted) держит ли снимок БД ?
    #39700732
gav21
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Павел Лузанов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 приводят к распуханию таблиц.

Павел, изучая это видео
YouTube Video
...
Рейтинг: 0 / 0
idle in transaction (aborted) держит ли снимок БД ?
    #39701028
Павел Лузанов
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
gav21,

Вот теперь всё встало на свои места, спасибо!

Действительно если первая транзакция получила номер (что-то изменяла: DML или DDL неважно), то она будет мешать очистке vacuum.
Приведенный пример это отлично иллюстрирует.
И хотя для транзакции в первой сессии удаленные версии строк таблицы vt не нужны, тем не менее именно она мешает вакууму.

Чуток переделал пример, чтобы номер транзакции был виден.

Первая сессия:
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
postgres=# select 1 as id into t;
SELECT 1
postgres=# begin isolation level read committed ;
BEGIN
postgres=# select txid_current();
 txid_current 
--------------
        122853 

Вторая сессия:
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
postgres=# delete from t;
DELETE 1
postgres=# vacuum verbose t;
INFO:  vacuuming "public.t"
INFO:  "t": found 0 removable, 1 nonremovable row versions in 1 out of 1 pages
 DETAIL:  1 dead row versions cannot be removed yet, oldest xmin: 122853 
There were 0 unused item pointers.
Skipped 0 pages due to buffer pins, 0 frozen pages.
0 pages are entirely empty.
CPU: user: 0.00 s, system: 0.00 s, elapsed: 0.00 s.
VACUUM
...
Рейтинг: 0 / 0
13 сообщений из 13, страница 1 из 1
Форумы / PostgreSQL [игнор отключен] [закрыт для гостей] / idle in transaction (aborted) держит ли снимок БД ?
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]