On 04.11.2018 9:31, Peter Geoghegan wrote:
On Sat, Nov 3, 2018 at 8:52 PM Andrey Lepikhov
<a.lepik...@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
