In general I would answer an initial question that idle in transaction (aborted) holds nothing.
But it would be desirable to explain here what moment.
Often I hear that is simple idle in transaction influences on bloat, here and Maxim hints at it:
Maxim Boguk wrote:
whether I strongly suspect a question was influences idle in transaction (aborted) on bloat just as simply idle in transaction ...
It would be desirable to understand in which image.
The matter is that simple experiments of this influence do not show (provided that transaction by default in READ COMMITTED).
The first session:
postgres=# create table t (id int);
postgres=# insert into t values (1);
INSERT 0 1
postgres=# begin isolation level read committed;
postgres=# select *, pg_backend_pid () from t;
id | pg_backend_pid
1 | 3876
The second session:
postgres=# select state from pg_stat_activity where pid =3876;
idle in transaction
postgres=# delete from t where id = 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
Apparently, hinders nothing to vacuum to clean the remote version of a line, though the first transaction in idle in transaction.
Swelling does not happen.
I suspect that life more richly, but where a dirty trick?