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

On Sun, Mar 24, 2019 at 10:33 AM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> > 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.

All that it will take to fix dependency.sql is to move an existing
\set VERBOSITY terse a few lines earlier.

I would like to suppress the dependency.sql stability issue right
away. I can also suppress the rowsecurity.out output in the same
commit. I want to fix the problem on the buildfarm first, unless your
well-principled approach won't take very long. Which seems unlikely.
You can revert these commits if and when they become unnecessary.

> 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.

That seems like a good argument to me.

> 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.

I agree that it isn't worth worrying about an OOM for the sort here.

--
Peter Geoghegan