Peter Geoghegan <p...@bowt.ie> writes: > On Sun, Mar 24, 2019 at 10:33 AM Tom Lane <t...@sss.pgh.pa.us> wrote: >> 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 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. I think I can probably get that done today, but if you don't want to wait, feel free to put in the detail-suppression for now. >> 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. If we aren't going to worry about that then I think it probably becomes a pretty simple change. Will look in a little bit. regards, tom lane