Re: ignore_system_indexes affects DROP SCHEMA ... CASCADE reportednumber of objects dropped
От | Peter Geoghegan |
---|---|
Тема | Re: ignore_system_indexes affects DROP SCHEMA ... CASCADE reportednumber of objects dropped |
Дата | |
Msg-id | CAH2-WzmMn50EwhLZjph4KQJy39SG_y5c3cij9=41GFgd2pz+Xg@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: ignore_system_indexes affects DROP SCHEMA ... CASCADE reported number of objects dropped (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: ignore_system_indexes affects DROP SCHEMA ... CASCADE reportednumber of objects dropped
|
Список | pgsql-hackers |
On Thu, May 3, 2018 at 3:18 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > Peter Geoghegan <pg@bowt.ie> writes: >> Why should the drop cascade to 63 objects rather than 62 because I've >> set ignore_system_indexes=on? > > Indeed, that seems weird. Maybe tweak the test scripts so you can see > all the objects cascaded to, and then find out what the additional > object is? (I think also you could look into the postmaster log, > without changing the test.) I wrote a patch that makes ignore_system_indexes=off agree with ignore_system_indexes=on in the two specific places I see problems (the create_view and collate tests). Actually, I started with the patch, and only ended up finding this issue later, while debugging my own work. The goal of this patch of mine is to have nbtree use heap TID as a unique-ifier -- an implicit "final column" that is a first class part of the key space (we sometimes have to store an "extra" heap TID attribute in internal page tuples to make this work across the entire tree structure). Vadim wanted to do something like this about 20 years ago, and I think he had the right idea -- it's more or less what Lehman and Yao intended. I don't actually know what the problem is just yet, but I suspect some subtle nbtree issue. I haven't actually debugged the underlying issue at all just yet, but I'll start on that now. I don't want to post my patch, since it's very much still a work in progress, and I'm not yet 100% sure that it actually truly fixes the issue. -- Peter Geoghegan
В списке pgsql-hackers по дате отправления: