diff options
| author | Alvaro Herrera <alvherre@alvh.no-ip.org> | 2024-06-11 11:38:45 +0200 |
|---|---|---|
| committer | Alvaro Herrera <alvherre@alvh.no-ip.org> | 2024-06-11 11:38:45 +0200 |
| commit | bf78abebf3e5c827a48186b2b1388c691e16fafc (patch) | |
| tree | ff5c4712736c088aeae6bb60b2dd2a3c731e83dd /src/backend/executor/nodeModifyTable.c | |
| parent | c7972f12261717dfb1009096a45babcb2f9b5275 (diff) | |
| download | postgresql-bf78abebf3e5c827a48186b2b1388c691e16fafc.tar.gz postgresql-bf78abebf3e5c827a48186b2b1388c691e16fafc.zip | |
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
Diffstat (limited to 'src/backend/executor/nodeModifyTable.c')
0 files changed, 0 insertions, 0 deletions