pg.ddx.io pgsql-committers@postgresql.org mailing list archivehelp / color / mirror / Atom feed
pgsql: Back-patch "Refactor code in tablecmds.c to check and process ta 2+ messages / 1 participants [nested] [flat]
* pgsql: Back-patch "Refactor code in tablecmds.c to check and process ta @ 2024-09-24 22:27 Noah Misch <noah@leadboat.com> 0 siblings, 0 replies; 2+ messages in thread From: Noah Misch @ 2024-09-24 22:27 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org Back-patch "Refactor code in tablecmds.c to check and process tablespace moves" Back-patch commits 4c9c359d38ff1e2de388eedd860785be6a49201c and 24843297a96d7be16cc3f4b090aacfc6e5e6839e to v13 and v12. Before those commits, we held the modifiable copy of the relation's pg_class row throughout a table_relation_copy_data(). That can last long enough to copy MaxBlockNumber of data. A subsequent fix will hold LockTuple() for the lifespan of that modifiable copy. By back-patching this first, we avoid a needless long-duration LOCKTAG_TUPLE. Discussion: https://postgr.es/m/20231027214946.79.nmisch@google.com Branch ------ REL_13_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/1299564cb9c787de3068777eaf8440fd0fceca4a Modified Files -------------- src/backend/commands/tablecmds.c | 210 ++++++++++++++++++++++----------------- src/include/commands/tablecmds.h | 4 + 2 files changed, 123 insertions(+), 91 deletions(-) ^ permalink raw reply [nested|flat] 2+ messages in thread
* pgsql: Back-patch "Refactor code in tablecmds.c to check and process ta @ 2024-09-24 22:27 Noah Misch <noah@leadboat.com> 0 siblings, 0 replies; 2+ messages in thread From: Noah Misch @ 2024-09-24 22:27 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org Back-patch "Refactor code in tablecmds.c to check and process tablespace moves" Back-patch commits 4c9c359d38ff1e2de388eedd860785be6a49201c and 24843297a96d7be16cc3f4b090aacfc6e5e6839e to v13 and v12. Before those commits, we held the modifiable copy of the relation's pg_class row throughout a table_relation_copy_data(). That can last long enough to copy MaxBlockNumber of data. A subsequent fix will hold LockTuple() for the lifespan of that modifiable copy. By back-patching this first, we avoid a needless long-duration LOCKTAG_TUPLE. Discussion: https://postgr.es/m/20231027214946.79.nmisch@google.com Branch ------ REL_12_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/dc845383cd12dcbb09b468b2eea94bf549528a4b Modified Files -------------- src/backend/commands/tablecmds.c | 210 ++++++++++++++++++++++----------------- src/include/commands/tablecmds.h | 4 + 2 files changed, 123 insertions(+), 91 deletions(-) ^ permalink raw reply [nested|flat] 2+ messages in thread
end of thread, other threads:[~2024-09-24 22:27 UTC | newest] Thread overview: 2+ messages (download: mbox mbox.gz follow: Atom feed) -- links below jump to the message on this page -- 2024-09-24 22:27 pgsql: Back-patch "Refactor code in tablecmds.c to check and process ta Noah Misch <noah@leadboat.com> 2024-09-24 22:27 pgsql: Back-patch "Refactor code in tablecmds.c to check and process ta Noah Misch <noah@leadboat.com>
This inbox is served by DDX for PostgreSQL; see mirroring instructions for how to clone and mirror all data and code used for this inbox