pg.ddx.io pgsql-committers@postgresql.org mailing list archivehelp / color / mirror / Atom feed
pgsql: Fix creation of partition descriptor during concurrent detach 11+ messages / 1 participants [nested] [flat]
* pgsql: Fix creation of partition descriptor during concurrent detach @ 2024-06-11 09:52 Alvaro Herrera <alvherre@alvh.no-ip.org> 0 siblings, 0 replies; 11+ messages in thread From: Alvaro Herrera @ 2024-06-11 09:52 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org Fix creation of partition descriptor during concurrent detach When a partition is being detached in concurrent mode, it is possible for find_inheritance_children_extended() to return that partition in the list, and immediately after that receive an invalidation message that sets its relpartbound to NULL just before we read it. (This can happen because table_open() reads invalidation messages.) Currently we raise an error ERROR: missing relpartbound for relation %u about the situation, but that's bogus because the table is no longer a partition, so we shouldn't be complaining about it. A better reaction is to retry the find_inheritance_children_extended call to get a new list, which will no longer have the partition being detached. Noticed while investigating bug #18377. Backpatch to 14, where DETACH CONCURRENTLY appeared. Discussion: https://postgr.es/m/202405201616.y4ht2qe5ihoy@alvherre.pgsql Branch ------ REL_16_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/bf78abebf3e5c827a48186b2b1388c691e16fafc Modified Files -------------- src/backend/partitioning/partdesc.c | 53 ++++++++++++++++++++++++++++--------- 1 file changed, 40 insertions(+), 13 deletions(-) ^ permalink raw reply [nested|flat] 11+ messages in thread
* pgsql: Fix creation of partition descriptor during concurrent detach @ 2024-06-11 09:52 Alvaro Herrera <alvherre@alvh.no-ip.org> 0 siblings, 0 replies; 11+ messages in thread From: Alvaro Herrera @ 2024-06-11 09:52 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org Fix creation of partition descriptor during concurrent detach When a partition is being detached in concurrent mode, it is possible for find_inheritance_children_extended() to return that partition in the list, and immediately after that receive an invalidation message that sets its relpartbound to NULL just before we read it. (This can happen because table_open() reads invalidation messages.) Currently we raise an error ERROR: missing relpartbound for relation %u about the situation, but that's bogus because the table is no longer a partition, so we shouldn't be complaining about it. A better reaction is to retry the find_inheritance_children_extended call to get a new list, which will no longer have the partition being detached. Noticed while investigating bug #18377. Backpatch to 14, where DETACH CONCURRENTLY appeared. Discussion: https://postgr.es/m/202405201616.y4ht2qe5ihoy@alvherre.pgsql Branch ------ REL_14_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/5dcaefc6a0cf35e3afed0a38216a463d736fff5b Modified Files -------------- src/backend/partitioning/partdesc.c | 53 ++++++++++++++++++++++++++++--------- 1 file changed, 40 insertions(+), 13 deletions(-) ^ permalink raw reply [nested|flat] 11+ messages in thread
* pgsql: Fix creation of partition descriptor during concurrent detach @ 2024-06-11 09:52 Alvaro Herrera <alvherre@alvh.no-ip.org> 0 siblings, 0 replies; 11+ messages in thread From: Alvaro Herrera @ 2024-06-11 09:52 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org Fix creation of partition descriptor during concurrent detach When a partition is being detached in concurrent mode, it is possible for find_inheritance_children_extended() to return that partition in the list, and immediately after that receive an invalidation message that sets its relpartbound to NULL just before we read it. (This can happen because table_open() reads invalidation messages.) Currently we raise an error ERROR: missing relpartbound for relation %u about the situation, but that's bogus because the table is no longer a partition, so we shouldn't be complaining about it. A better reaction is to retry the find_inheritance_children_extended call to get a new list, which will no longer have the partition being detached. Noticed while investigating bug #18377. Backpatch to 14, where DETACH CONCURRENTLY appeared. Discussion: https://postgr.es/m/202405201616.y4ht2qe5ihoy@alvherre.pgsql Branch ------ REL_15_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/03c8cdbb7e75669322d3084dfc918b721c77f076 Modified Files -------------- src/backend/partitioning/partdesc.c | 53 ++++++++++++++++++++++++++++--------- 1 file changed, 40 insertions(+), 13 deletions(-) ^ permalink raw reply [nested|flat] 11+ messages in thread
* pgsql: Fix creation of partition descriptor during concurrent detach @ 2024-06-11 09:52 Alvaro Herrera <alvherre@alvh.no-ip.org> 0 siblings, 0 replies; 11+ messages in thread From: Alvaro Herrera @ 2024-06-11 09:52 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org Fix creation of partition descriptor during concurrent detach When a partition is being detached in concurrent mode, it is possible for find_inheritance_children_extended() to return that partition in the list, and immediately after that receive an invalidation message that sets its relpartbound to NULL just before we read it. (This can happen because table_open() reads invalidation messages.) Currently we raise an error ERROR: missing relpartbound for relation %u about the situation, but that's bogus because the table is no longer a partition, so we shouldn't be complaining about it. A better reaction is to retry the find_inheritance_children_extended call to get a new list, which will no longer have the partition being detached. Noticed while investigating bug #18377. Backpatch to 14, where DETACH CONCURRENTLY appeared. Discussion: https://postgr.es/m/202405201616.y4ht2qe5ihoy@alvherre.pgsql Branch ------ master Details ------- https://git.postgresql.org/pg/commitdiff/c2fab70248d8b9f129d2333c91b7a6e279a591e3 Modified Files -------------- src/backend/partitioning/partdesc.c | 54 ++++++++++++++++++++++++++++--------- 1 file changed, 41 insertions(+), 13 deletions(-) ^ permalink raw reply [nested|flat] 11+ messages in thread
* pgsql: Fix creation of partition descriptor during concurrent detach+dr @ 2024-08-12 22:18 Alvaro Herrera <alvherre@alvh.no-ip.org> 0 siblings, 0 replies; 11+ messages in thread From: Alvaro Herrera @ 2024-08-12 22:18 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org Fix creation of partition descriptor during concurrent detach+drop If a partition undergoes DETACH CONCURRENTLY immediately followed by DROP, this could cause a problem for a concurrent transaction recomputing the partition descriptor when running a prepared statement, because it tries to dereference a pointer to a tuple that's not found in a catalog scan. The existing retry logic added in commit dbca3469ebf8 is sufficient to cope with the overall problem, provided we don't try to dereference a non-existant heap tuple. Arguably, the code in RelationBuildPartitionDesc() has been wrong all along, since no check was added in commit 898e5e3290a7 against receiving a NULL tuple from the catalog scan; that bug has only become user-visible with DETACH CONCURRENTLY which was added in branch 14. Therefore, even though there's no known mechanism to cause a crash because of this, backpatch the addition of such a check to all supported branches. In branches prior to 14, this would cause the code to fail with a "missing relpartbound for relation XYZ" error instead of crashing; that's okay, because there are no reports of such behavior anyway. Author: Kuntal Ghosh <kuntalghosh.2007@gmail.com> Reviewed-by: Junwang Zhao <zhjwpku@gmail.com> Reviewed-by: Tender Wang <tndrwang@gmail.com> Discussion: https://postgr.es/m/18559-b48286d2eacd9a4e@postgresql.org Branch ------ REL_17_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/0820f80622ed415a88d2c79b04d292ae79023f50 Modified Files -------------- src/backend/partitioning/partdesc.c | 30 ++++++++++++++++++++++-------- 1 file changed, 22 insertions(+), 8 deletions(-) ^ permalink raw reply [nested|flat] 11+ messages in thread
* pgsql: Fix creation of partition descriptor during concurrent detach+dr @ 2024-08-12 22:18 Alvaro Herrera <alvherre@alvh.no-ip.org> 0 siblings, 0 replies; 11+ messages in thread From: Alvaro Herrera @ 2024-08-12 22:18 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org Fix creation of partition descriptor during concurrent detach+drop If a partition undergoes DETACH CONCURRENTLY immediately followed by DROP, this could cause a problem for a concurrent transaction recomputing the partition descriptor when running a prepared statement, because it tries to dereference a pointer to a tuple that's not found in a catalog scan. The existing retry logic added in commit dbca3469ebf8 is sufficient to cope with the overall problem, provided we don't try to dereference a non-existant heap tuple. Arguably, the code in RelationBuildPartitionDesc() has been wrong all along, since no check was added in commit 898e5e3290a7 against receiving a NULL tuple from the catalog scan; that bug has only become user-visible with DETACH CONCURRENTLY which was added in branch 14. Therefore, even though there's no known mechanism to cause a crash because of this, backpatch the addition of such a check to all supported branches. In branches prior to 14, this would cause the code to fail with a "missing relpartbound for relation XYZ" error instead of crashing; that's okay, because there are no reports of such behavior anyway. Author: Kuntal Ghosh <kuntalghosh.2007@gmail.com> Reviewed-by: Junwang Zhao <zhjwpku@gmail.com> Reviewed-by: Tender Wang <tndrwang@gmail.com> Discussion: https://postgr.es/m/18559-b48286d2eacd9a4e@postgresql.org Branch ------ REL_15_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/305db95434c9f68811f2489ec57d5a0435608c46 Modified Files -------------- src/backend/partitioning/partdesc.c | 30 ++++++++++++++++++++++-------- 1 file changed, 22 insertions(+), 8 deletions(-) ^ permalink raw reply [nested|flat] 11+ messages in thread
* pgsql: Fix creation of partition descriptor during concurrent detach+dr @ 2024-08-12 22:18 Alvaro Herrera <alvherre@alvh.no-ip.org> 0 siblings, 0 replies; 11+ messages in thread From: Alvaro Herrera @ 2024-08-12 22:18 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org Fix creation of partition descriptor during concurrent detach+drop If a partition undergoes DETACH CONCURRENTLY immediately followed by DROP, this could cause a problem for a concurrent transaction recomputing the partition descriptor when running a prepared statement, because it tries to dereference a pointer to a tuple that's not found in a catalog scan. The existing retry logic added in commit dbca3469ebf8 is sufficient to cope with the overall problem, provided we don't try to dereference a non-existant heap tuple. Arguably, the code in RelationBuildPartitionDesc() has been wrong all along, since no check was added in commit 898e5e3290a7 against receiving a NULL tuple from the catalog scan; that bug has only become user-visible with DETACH CONCURRENTLY which was added in branch 14. Therefore, even though there's no known mechanism to cause a crash because of this, backpatch the addition of such a check to all supported branches. In branches prior to 14, this would cause the code to fail with a "missing relpartbound for relation XYZ" error instead of crashing; that's okay, because there are no reports of such behavior anyway. Author: Kuntal Ghosh <kuntalghosh.2007@gmail.com> Reviewed-by: Junwang Zhao <zhjwpku@gmail.com> Reviewed-by: Tender Wang <tndrwang@gmail.com> Discussion: https://postgr.es/m/18559-b48286d2eacd9a4e@postgresql.org Branch ------ REL_13_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/5236dcdb62ac9da00a993e0971fac4ba5e240070 Modified Files -------------- src/backend/partitioning/partdesc.c | 16 ++++++++++------ 1 file changed, 10 insertions(+), 6 deletions(-) ^ permalink raw reply [nested|flat] 11+ messages in thread
* pgsql: Fix creation of partition descriptor during concurrent detach+dr @ 2024-08-12 22:18 Alvaro Herrera <alvherre@alvh.no-ip.org> 0 siblings, 0 replies; 11+ messages in thread From: Alvaro Herrera @ 2024-08-12 22:18 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org Fix creation of partition descriptor during concurrent detach+drop If a partition undergoes DETACH CONCURRENTLY immediately followed by DROP, this could cause a problem for a concurrent transaction recomputing the partition descriptor when running a prepared statement, because it tries to dereference a pointer to a tuple that's not found in a catalog scan. The existing retry logic added in commit dbca3469ebf8 is sufficient to cope with the overall problem, provided we don't try to dereference a non-existant heap tuple. Arguably, the code in RelationBuildPartitionDesc() has been wrong all along, since no check was added in commit 898e5e3290a7 against receiving a NULL tuple from the catalog scan; that bug has only become user-visible with DETACH CONCURRENTLY which was added in branch 14. Therefore, even though there's no known mechanism to cause a crash because of this, backpatch the addition of such a check to all supported branches. In branches prior to 14, this would cause the code to fail with a "missing relpartbound for relation XYZ" error instead of crashing; that's okay, because there are no reports of such behavior anyway. Author: Kuntal Ghosh <kuntalghosh.2007@gmail.com> Reviewed-by: Junwang Zhao <zhjwpku@gmail.com> Reviewed-by: Tender Wang <tndrwang@gmail.com> Discussion: https://postgr.es/m/18559-b48286d2eacd9a4e@postgresql.org Branch ------ master Details ------- https://git.postgresql.org/pg/commitdiff/c899c6839f5de596a316da7fb94e4f917a242b04 Modified Files -------------- src/backend/partitioning/partdesc.c | 30 ++++++++++++++++++++++-------- 1 file changed, 22 insertions(+), 8 deletions(-) ^ permalink raw reply [nested|flat] 11+ messages in thread
* pgsql: Fix creation of partition descriptor during concurrent detach+dr @ 2024-08-12 22:18 Alvaro Herrera <alvherre@alvh.no-ip.org> 0 siblings, 0 replies; 11+ messages in thread From: Alvaro Herrera @ 2024-08-12 22:18 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org Fix creation of partition descriptor during concurrent detach+drop If a partition undergoes DETACH CONCURRENTLY immediately followed by DROP, this could cause a problem for a concurrent transaction recomputing the partition descriptor when running a prepared statement, because it tries to dereference a pointer to a tuple that's not found in a catalog scan. The existing retry logic added in commit dbca3469ebf8 is sufficient to cope with the overall problem, provided we don't try to dereference a non-existant heap tuple. Arguably, the code in RelationBuildPartitionDesc() has been wrong all along, since no check was added in commit 898e5e3290a7 against receiving a NULL tuple from the catalog scan; that bug has only become user-visible with DETACH CONCURRENTLY which was added in branch 14. Therefore, even though there's no known mechanism to cause a crash because of this, backpatch the addition of such a check to all supported branches. In branches prior to 14, this would cause the code to fail with a "missing relpartbound for relation XYZ" error instead of crashing; that's okay, because there are no reports of such behavior anyway. Author: Kuntal Ghosh <kuntalghosh.2007@gmail.com> Reviewed-by: Junwang Zhao <zhjwpku@gmail.com> Reviewed-by: Tender Wang <tndrwang@gmail.com> Discussion: https://postgr.es/m/18559-b48286d2eacd9a4e@postgresql.org Branch ------ REL_14_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/1b4bdf915861e9c7ba5a9223c55d5ac0eccccdb1 Modified Files -------------- src/backend/partitioning/partdesc.c | 30 ++++++++++++++++++++++-------- 1 file changed, 22 insertions(+), 8 deletions(-) ^ permalink raw reply [nested|flat] 11+ messages in thread
* pgsql: Fix creation of partition descriptor during concurrent detach+dr @ 2024-08-12 22:18 Alvaro Herrera <alvherre@alvh.no-ip.org> 0 siblings, 0 replies; 11+ messages in thread From: Alvaro Herrera @ 2024-08-12 22:18 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org Fix creation of partition descriptor during concurrent detach+drop If a partition undergoes DETACH CONCURRENTLY immediately followed by DROP, this could cause a problem for a concurrent transaction recomputing the partition descriptor when running a prepared statement, because it tries to dereference a pointer to a tuple that's not found in a catalog scan. The existing retry logic added in commit dbca3469ebf8 is sufficient to cope with the overall problem, provided we don't try to dereference a non-existant heap tuple. Arguably, the code in RelationBuildPartitionDesc() has been wrong all along, since no check was added in commit 898e5e3290a7 against receiving a NULL tuple from the catalog scan; that bug has only become user-visible with DETACH CONCURRENTLY which was added in branch 14. Therefore, even though there's no known mechanism to cause a crash because of this, backpatch the addition of such a check to all supported branches. In branches prior to 14, this would cause the code to fail with a "missing relpartbound for relation XYZ" error instead of crashing; that's okay, because there are no reports of such behavior anyway. Author: Kuntal Ghosh <kuntalghosh.2007@gmail.com> Reviewed-by: Junwang Zhao <zhjwpku@gmail.com> Reviewed-by: Tender Wang <tndrwang@gmail.com> Discussion: https://postgr.es/m/18559-b48286d2eacd9a4e@postgresql.org Branch ------ REL_12_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/559ae1336e030c427e6a7df3ad59e657fd77734c Modified Files -------------- src/backend/partitioning/partdesc.c | 16 ++++++++++------ 1 file changed, 10 insertions(+), 6 deletions(-) ^ permalink raw reply [nested|flat] 11+ messages in thread
* pgsql: Fix creation of partition descriptor during concurrent detach+dr @ 2024-08-12 22:18 Alvaro Herrera <alvherre@alvh.no-ip.org> 0 siblings, 0 replies; 11+ messages in thread From: Alvaro Herrera @ 2024-08-12 22:18 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org Fix creation of partition descriptor during concurrent detach+drop If a partition undergoes DETACH CONCURRENTLY immediately followed by DROP, this could cause a problem for a concurrent transaction recomputing the partition descriptor when running a prepared statement, because it tries to dereference a pointer to a tuple that's not found in a catalog scan. The existing retry logic added in commit dbca3469ebf8 is sufficient to cope with the overall problem, provided we don't try to dereference a non-existant heap tuple. Arguably, the code in RelationBuildPartitionDesc() has been wrong all along, since no check was added in commit 898e5e3290a7 against receiving a NULL tuple from the catalog scan; that bug has only become user-visible with DETACH CONCURRENTLY which was added in branch 14. Therefore, even though there's no known mechanism to cause a crash because of this, backpatch the addition of such a check to all supported branches. In branches prior to 14, this would cause the code to fail with a "missing relpartbound for relation XYZ" error instead of crashing; that's okay, because there are no reports of such behavior anyway. Author: Kuntal Ghosh <kuntalghosh.2007@gmail.com> Reviewed-by: Junwang Zhao <zhjwpku@gmail.com> Reviewed-by: Tender Wang <tndrwang@gmail.com> Discussion: https://postgr.es/m/18559-b48286d2eacd9a4e@postgresql.org Branch ------ REL_16_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/1b9dd6b05a27ad96a027a0b8ab1e5efd418605a2 Modified Files -------------- src/backend/partitioning/partdesc.c | 30 ++++++++++++++++++++++-------- 1 file changed, 22 insertions(+), 8 deletions(-) ^ permalink raw reply [nested|flat] 11+ messages in thread
end of thread, other threads:[~2024-08-12 22:18 UTC | newest] Thread overview: 11+ messages (download: mbox mbox.gz follow: Atom feed) -- links below jump to the message on this page -- 2024-06-11 09:52 pgsql: Fix creation of partition descriptor during concurrent detach Alvaro Herrera <alvherre@alvh.no-ip.org> 2024-06-11 09:52 pgsql: Fix creation of partition descriptor during concurrent detach Alvaro Herrera <alvherre@alvh.no-ip.org> 2024-06-11 09:52 pgsql: Fix creation of partition descriptor during concurrent detach Alvaro Herrera <alvherre@alvh.no-ip.org> 2024-06-11 09:52 pgsql: Fix creation of partition descriptor during concurrent detach Alvaro Herrera <alvherre@alvh.no-ip.org> 2024-08-12 22:18 pgsql: Fix creation of partition descriptor during concurrent detach+dr Alvaro Herrera <alvherre@alvh.no-ip.org> 2024-08-12 22:18 pgsql: Fix creation of partition descriptor during concurrent detach+dr Alvaro Herrera <alvherre@alvh.no-ip.org> 2024-08-12 22:18 pgsql: Fix creation of partition descriptor during concurrent detach+dr Alvaro Herrera <alvherre@alvh.no-ip.org> 2024-08-12 22:18 pgsql: Fix creation of partition descriptor during concurrent detach+dr Alvaro Herrera <alvherre@alvh.no-ip.org> 2024-08-12 22:18 pgsql: Fix creation of partition descriptor during concurrent detach+dr Alvaro Herrera <alvherre@alvh.no-ip.org> 2024-08-12 22:18 pgsql: Fix creation of partition descriptor during concurrent detach+dr Alvaro Herrera <alvherre@alvh.no-ip.org> 2024-08-12 22:18 pgsql: Fix creation of partition descriptor during concurrent detach+dr Alvaro Herrera <alvherre@alvh.no-ip.org>
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