Hi,
while reviewing another patch I noticed that REPACK is trying to access
temp tables from other sessions.
== session 1 ==
$ psql postgres
psql (19devel)
Type "help" for help.
postgres=# SELECT pg_backend_pid();
pg_backend_pid
----------------
730392
(1 row)
postgres=# CREATE TEMP TABLE tmp AS SELECT generate_series(1, 1000) AS id;
SELECT 1000
postgres=# BEGIN;
LOCK TABLE tmp IN SHARE MODE;
BEGIN
LOCK TABLE
postgres=*#
== session 2 ==
$ psql postgres
psql (19devel)
Type "help" for help.
postgres=# REPACK;
(waits for LOCK)
== session 3 ==
$ psql postgres
psql (19devel)
Type "help" for help.
postgres=# SELECT pid, relation::regclass, mode, granted
FROM pg_locks
WHERE relation::regclass::text ~~ '%.tmp%';
pid | relation | mode | granted
--------+----------------+---------------------+---------
730608 | pg_temp_12.tmp | AccessExclusiveLock | f
730392 | pg_temp_12.tmp | ShareLock | t
(2 rows)
The same applies for REPACK USING INDEX if indisclustered is true.
I played a bit with the code and perhaps skipping temp relations in
get_tables_to_repack() before they're added to the list can do the
trick. I tried the draft attached and REPACK could run despite the LOCK
in the other session... in case it helps.
Best, Jim
