From: Tom Lane <tgl@sss.pgh.pa.us>
To: Peter Geoghegan <pg@bowt.ie>
cc: pgsql-committers <pgsql-committers@lists.postgresql.org>
Subject: Re: pgsql: Make heap TID a tiebreaker nbtree index column.
In-reply-to: 
 <CAH2-WzkYwR_KDMyWgyxu9H3-7w4AV=w7ehHuh0TL6J8xR-aa7g@mail.gmail.com>
References: <E1h6eep-0001Mw-Vd@gemulon.postgresql.org>
 <CAH2-WzmFdW-e9+uG5BqzuW7YWBdL9=Vrwgmt5p6vndCeKJ5Z4w@mail.gmail.com>
 <13999.1553105283@sss.pgh.pa.us>
 <CAH2-Wznu+i765yrRcpKC0m9N2LEFWg=stjF73U7XmakSXWDDAg@mail.gmail.com>
 <CAH2-WzkCQ_MtKeOpzozj7QhhgP1unXsK8o9DMAFvDqQFEPpkYQ@mail.gmail.com>
 <24277.1553114810@sss.pgh.pa.us> <16667.1553116435@sss.pgh.pa.us>
 <17604.1553118255@sss.pgh.pa.us>
 <CAH2-WzmfxXs3bSX6T3DP1wTEWbyhkTiyPZ6o9t2DmcHbBtsCNA@mail.gmail.com>
 <17845.1553118645@sss.pgh.pa.us> <8748.1553119737@sss.pgh.pa.us>
 <CAH2-Wz=U8tcaP1wx4t2n8-grz-9ar2fPJeYu9MExSyOu_NVmiA@mail.gmail.com>
 <CAH2-Wzm0nQyV3x06_XEuH62tda8X6op-4r29uj8VA0XambsUpw@mail.gmail.com>
 <21983.1553138224@sss.pgh.pa.us>
 <CAH2-WzmMakut=D8=TnmzhGtB+ELbb6k84LYNW28C8MZ2D-ZoJw@mail.gmail.com>
 <5446.1553272377@sss.pgh.pa.us> <6226.1553274783@sss.pgh.pa.us>
 <CAH2-Wzny8NVzgvx=n6nBE9xNEf-W5o=ri2Dq3kspYmgDHtrHDw@mail.gmail.com>
 <4642.1553276304@sss.pgh.pa.us> <22259.1553441524@sss.pgh.pa.us>
 <CAH2-WzkGNpcWMMC8oW=Qb!
 pt_4aVeQJAgRJmNEJ3B3TyShEwdLA@mail.gmail.com>
 <27112.1553448806@sss.pgh.pa.us>
 <CAH2-WzkYwR_KDMyWgyxu9H3-7w4AV=w7ehHuh0TL6J8xR-aa7g@mail.gmail.com>
Comments: In-reply-to Peter Geoghegan <pg@bowt.ie>
	message dated "Sun, 24 Mar 2019 10:44:34 -0700"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <28073.1553450544.1@sss.pgh.pa.us>
Date: Sun, 24 Mar 2019 14:02:24 -0400
Message-ID: <28074.1553450544@sss.pgh.pa.us>
Precedence: bulk

Peter Geoghegan <pg@bowt.ie> writes:
> On Sun, Mar 24, 2019 at 10:33 AM Tom Lane <tgl@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