Re: find_inheritance_children() and ALTER TABLE NO INHERIT
| От | Amit Langote |
|---|---|
| Тема | Re: find_inheritance_children() and ALTER TABLE NO INHERIT |
| Дата | |
| Msg-id | 566FA50E.3080709@lab.ntt.co.jp обсуждение исходный текст |
| Ответ на | Re: find_inheritance_children() and ALTER TABLE NO INHERIT (Amit Langote <Langote_Amit_f8@lab.ntt.co.jp>) |
| Список | pgsql-hackers |
On 2015/12/03 15:30, Amit Langote wrote: > On 2015/12/03 13:09, Tom Lane wrote: >> Amit Langote <Langote_Amit_f8@lab.ntt.co.jp> writes: >>> Currently find_inheritance_children() is smart enough to skip a child >>> table that it finds has been dropped concurrently after it gets a lock on >>> the same. It does so by looking up the child relid in syscache. It seems >>> it should also check if the table is still in the list of children of the >>> parent. > >> I wonder whether we could improve matters by rechecking validity of the >> pg_inherits tuple (which we saw already and could presumably retain the >> TID of). There is at least one place where we do something like that now, >> IIRC. > > Not sure whether sane but how about performing ordered scan on pg_inherits > (systable_getnext_ordered())and using systable_recheck_tuple() in step > with it? Does using ordered catalog scan ensure safety against deadlocks > that the existing approach of ordered locking of child tables does? > Perhaps I'm missing something. Just leaving here a patch that does this. It still returns the list in order determined by qsort(), IOW, not in the pg_inherits_parent_index order to avoid broken tests. I could not figure how to do it the way you suggested. Thanks, Amit
Вложения
В списке pgsql-hackers по дате отправления: