Re: pgsql: Make heap TID a tiebreaker nbtree index column.

Peter Geoghegan <pg(at)bowt(dot)ie> writes:
> On Sun, Mar 24, 2019 at 8:32 AM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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.

At this point I no longer have any faith in the approach of "suppress
DETAIL only where we've actually been burnt". I think we should
either go ahead and suppress DETAIL in all four places, or bite the
bullet and change the DROP ROLE code as I sketched upthread.

I'm not sure how much test coverage we're really losing if we
suppress DETAIL in all these places. We would still have test output
from assorted places where DROP ROLE cascades to just one object,
so from a pure code-coverage standpoint doing that probably isn't
going to be too awful.

However, I don't really like the fact that we're setting up a booby
trap for all future tests involving DROP ROLE. I think if we leave
it like this, people are going to add new test cases that have
slightly unstable output and are going to learn about it the hard
way, just as we're doing now. When you take the long view of it,
there's definitely something to be said for expending the effort
to make the DROP ROLE results stable.

When I was looking at this on Friday, I thought it wouldn't be that
hard to make the results stable, at least up to whatever cutoff we
want to set on how many objects to sort. But per previous discussion,
maybe we don't need an explicit limit? The stringinfo describing the
objects is going to consume a good bit more memory than an ObjectAddress
array in any case, so if we're not going to sweat about OOM for the
message then I'm not sure we need to be paranoid about the sort memory.

regards, tom lane