agora inbox for pgsql-committers@postgresql.orghelp / color / mirror / Atom feed
pgsql: Don't lock tables in get_tables_to_repack() 2+ messages / 1 participants [nested] [flat]
* pgsql: Don't lock tables in get_tables_to_repack() @ 2026-07-10 14:11 Álvaro Herrera <alvherre@kurilemu.de> 0 siblings, 0 replies; 2+ messages in thread From: Álvaro Herrera @ 2026-07-10 14:11 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org 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 <cca5507@qq.com> Backpatch-through: 19 Discussion: https://postgr.es/m/tencent_9F290B256A3F52B66542F1140E32ECC64309@qq.com Branch ------ master Details ------- https://git.postgresql.org/pg/commitdiff/c71d43025d7aaf12fe461ec635bd2eda220c9f4a Modified Files -------------- src/backend/commands/repack.c | 117 +++++++++++++++++++----------------------- 1 file changed, 54 insertions(+), 63 deletions(-) ^ permalink raw reply [nested|flat] 2+ messages in thread
* pgsql: Don't lock tables in get_tables_to_repack() @ 2026-07-10 14:11 Álvaro Herrera <alvherre@kurilemu.de> 0 siblings, 0 replies; 2+ messages in thread From: Álvaro Herrera @ 2026-07-10 14:11 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org 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 <cca5507@qq.com> Backpatch-through: 19 Discussion: https://postgr.es/m/tencent_9F290B256A3F52B66542F1140E32ECC64309@qq.com 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(-) ^ permalink raw reply [nested|flat] 2+ messages in thread
end of thread, other threads:[~2026-07-10 14:11 UTC | newest] Thread overview: 2+ messages (download: mbox mbox.gz follow: Atom feed) -- links below jump to the message on this page -- 2026-07-10 14:11 pgsql: Don't lock tables in get_tables_to_repack() Álvaro Herrera <alvherre@kurilemu.de> 2026-07-10 14:11 pgsql: Don't lock tables in get_tables_to_repack() Álvaro Herrera <alvherre@kurilemu.de>
This inbox is served by agora; see mirroring instructions for how to clone and mirror all data and code used for this inbox