On Sun, Mar 24, 2019 at 8:32 AM Tom Lane <tgl@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