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 | 03c8cdbb7e75669322d3084dfc918b721c77f076 (patch) | |
| tree | 45c14f43db3d3cf4e034240d9dce9e79cf7a3aeb /src/backend/executor/nodeModifyTable.c | |
| parent | a8d747771fe59cd3cf7bc16029a3e4d01407a864 (diff) | |
| download | postgresql-03c8cdbb7e75669322d3084dfc918b721c77f076.tar.gz postgresql-03c8cdbb7e75669322d3084dfc918b721c77f076.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