Re: ALTER TABLE .. DETACH PARTITION CONCURRENTLY
| От | Álvaro Herrera |
|---|---|
| Тема | Re: ALTER TABLE .. DETACH PARTITION CONCURRENTLY |
| Дата | |
| Msg-id | f12cee75-02cc-43a7-bbd0-6487b8634934@www.fastmail.com обсуждение исходный текст |
| Ответ на | Re: ALTER TABLE .. DETACH PARTITION CONCURRENTLY (Amit Langote <amitlangote09@gmail.com>) |
| Ответы |
Re: ALTER TABLE .. DETACH PARTITION CONCURRENTLY
Re: ALTER TABLE .. DETACH PARTITION CONCURRENTLY |
| Список | pgsql-hackers |
Thanks for re-reviewing! This one I hope is the last version.
On Wed, Apr 28, 2021, at 10:21 AM, Amit Langote wrote:
I noticed that rd_partdesc_nodetached_xmin can sometimes end up withvalue 0. While you seem to be already aware of that, because otherwiseyou wouldn't have added TransactionIdIsValid(...) in condition inRelationGetPartitionDesc(), the comments nearby don't mention why sucha thing might happen. Also, I guess it can't be helped that thepartdesc_nodetached will have to be leaked when the xmin is 0, butthat shouldn't be as problematic as the case we discussed earlier.
The only case I am aware where that can happen is if the pg_inherits tuple is frozen. (That's exactly what the affected test case was testing, note the "VACUUM FREEZE pg_inherits" there). So that test case blew up immediately; but I think the real-world chances that people are going to be doing that are pretty low, so I'm not really concerned about the leak.
Would it be a bit more readable to just duplicate this stanza in theblocks that assign to rd_partdesc_nodetached and rd_partdesc,respectively? That's not much code to duplicate and it'd be easier tosee which context is for which partdesc.
Sure .. that's how I first wrote this code. We don't use that style much, so I'm OK with backing out of it.
+ TransactionId rd_partdesc_nodetached_xmin; /* xmin for the above */Could you please expand this description a bit?
Done.
Вложения
В списке pgsql-hackers по дате отправления: