Don't lock tables in get_tables_to_repack() When doing a whole database repack, we build a list of tables to process taking a lock on each. But because it's a regular transaction-scoped lock, it's automatically released immediately after building the list anyway, which makes it not very useful. (Also, we have three ways to obtain a list of tables to repack, and only one of them acquired this lock.) Remove that lock acquisition, as it's useless and inconsistent.
We acquire a lock properly afterwards (and recheck that the table can still be repacked as indicated), so we don't need to do anything other than drop that initial lock acquisition and harden the code in repack_is_permitted_for_relation() against possible concurrent drops. This is similar to how vacuum does it in get_all_vacuum_rels(). In order for this to work reliably, also change repack_is_permitted_for_relation() to cope with the possibility of the table going away partway through. Similarly, in ExecRepack(), be prepared for what we believed to be a table or matview to now be something else, and skip it without erroring out, by changing try_table_open() to try_relation_open() and testing the relkind separately. While at it, replace one relation_close() call in get_tables_to_repack() with table_close() to match the table_open() that opened the catalog. Author: ChangAo Chen <[email protected]> Backpatch-through: 19 Discussion: https://postgr.es/m/[email protected] Branch ------ REL_19_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/133eba078f776268d24f82a2b3d5bf9ca31dd4c3 Modified Files -------------- src/backend/commands/repack.c | 117 +++++++++++++++++++----------------------- 1 file changed, 54 insertions(+), 63 deletions(-)
