Re: Making all nbtree entries unique by having heap TIDs participatein comparisons
От | Andrey Lepikhov |
---|---|
Тема | Re: Making all nbtree entries unique by having heap TIDs participatein comparisons |
Дата | |
Msg-id | 553ac80e-2115-fdf3-22d9-c27de2bc4d45@postgrespro.ru обсуждение исходный текст |
Ответ на | Re: Making all nbtree entries unique by having heap TIDs participatein comparisons (Peter Geoghegan <pg@bowt.ie>) |
Ответы |
Re: Making all nbtree entries unique by having heap TIDs participatein comparisons
|
Список | pgsql-hackers |
On 04.11.2018 9:31, Peter Geoghegan wrote: > On Sat, Nov 3, 2018 at 8:52 PM Andrey Lepikhov > <a.lepikhov@postgrespro.ru> wrote: >> I applied your patches at top of master. After tests corrections >> (related to TID ordering in index relations DROP...CASCADE operation) >> 'make check-world' passed successfully many times. >> In the case of 'create view' regression test - 'drop cascades to 62 >> other objects' problem - I verify an Álvaro Herrera hypothesis [1] and >> it is true. You can verify it by tracking the >> object_address_present_add_flags() routine return value. > > I'll have to go and fix the problem directly, so that ASC sort order > can be used. > >> Some doubts, however, may be regarding the 'triggers' test. >> May you specify the test failures do you mean? > > Not sure what you mean. The order of items that are listed in the > DETAIL for a cascading DROP can have an "implementation defined" > order. I think that this is an example of the more general problem -- > what you call the 'drop cascades to 62 other objects' problem is a > more specific subproblem, or, if you prefer, a more specific symptom > of the same problem. I mean that your code have not any problems that I can detect by regression tests and by the retail index tuple deletion patch. Difference in amount of dropped objects is not a problem. It is caused by pos 2293 - 'else if (thisobj->objectSubId == 0)' - at the file catalog/dependency.c and it is legal behavior: column row object deleted without any report because we already decided to drop its whole table. Also, I checked the triggers test. Difference in the ERROR message 'cannot drop trigger trg1' is caused by different order of tuples in the relation with the dependDependerIndexId relid. It is legal behavior and we can simply replace test results. May be you know any another problems of the patch? -- Andrey Lepikhov Postgres Professional https://postgrespro.com The Russian Postgres Company
В списке pgsql-hackers по дате отправления: