>The order of table ID's is only significant during a LOCK SET 
>in preparation of switchover. If that order is different from 
>the order in which an application is acquiring its locks, it 
>can lead to deadlocks that abort either the application or slonik.

I ran into one other case where the ordering of tables in the set was
significant: in the
presence of inherited tables. If a child table appears before its parent
in a set,
then the initial subscription will end up deleting that child table
after it has possibly
already received data, because the copy_set logic does a "delete", not a
"delete only",
so the delete of the parent will delete the new rows in the child as
well.

- DAP