On Sun, Mar 24, 2019 at 8:32 AM Tom Lane <t...@sss.pgh.pa.us> wrote: > So here's another failure of the same ilk: > > https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=urocryon&dt=2019-03-24%2006%3A12%3A35
I can fix this one the same way as I fixed the first two. That will mean that three out of the four tests with DROP ROLE statements whose output needed to be changed as part of commit dd299df81 will have had their DETAIL output suppressed. It's still possible that the last instance of such a change (rowsecurity.out) will have a failure like this too. That will be the end of it, barring some new manifestation of the problem that we haven't seen already. Clearly I underestimated the likelihood of problems like this, but at least it's limited to DROP ROLE's DETAIL output. There just isn't that many tests that could be destabilized. > How come these results seem to be less stable than they used to be? Now that heap TID is just another column internally, the stability of results like this is dependent on whatever the process is through which TIDs are generated. They're not going to be placed at the first offset >= insertion scankey, which was what almost always happened before dd299df81. I think that pruning could affect the results, for example. Previously, it was mostly a matter of index insertion order, which looked like it made heap TIDs among duplicates be in descending order, though that certainly didn't happen reliably. -- Peter Geoghegan
