While running installcheck against a long-lived cluster, I got a diff in the foreign_key test:
@@ -2045,11 +2045,11 @@ ORDER BY oid::regclass::text; conname | conenforced | convalidated ------------+-------------+-------------- + selffk_3 | t | f + selffk_3_1 | t | f selffk | t | f selffk_1 | t | f selffk_2 | t | f - selffk_3 | t | f - selffk_3_1 | t | f (5 rows) At first I thought the planner patch I was working on had caused an unexpected plan diff, and wasted some time chasing that. But it turned out to be the "ORDER BY oid::regclass::text" in these queries. These OIDs are constraint OIDs, not relation OIDs, so the regclass cast just renders them as numeric strings, and comparing those as text depends on the number of digits. Once the OID counter crosses a power of ten while the test runs, '1000006' sorts before '999987' and the output order flips. I plan to push the attached patch to fix it. Any thoughts? - Richard
v1-0001-Fix-OID-counter-sensitive-row-ordering-in-foreign.patch
Description: Binary data
