From: Tom Lane <tgl@sss.pgh.pa.us>
To: Alvaro Herrera <alvherre@alvh.no-ip.org>
cc: Amul Sul <sulamul@gmail.com>,
        PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Subject: Re: tweak to a few index tests to hits ambuildempty() routine.
In-reply-to: <202204251353.vgkpgcy3szt2@alvherre.pgsql>
References: <202204251353.vgkpgcy3szt2@alvherre.pgsql>
Comments: In-reply-to Alvaro Herrera <alvherre@alvh.no-ip.org>
	message dated "Mon, 25 Apr 2022 15:53:10 +0200"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <39944.1650895508.1@sss.pgh.pa.us>
Date: Mon, 25 Apr 2022 10:05:08 -0400
Message-ID: <39945.1650895508@sss.pgh.pa.us>
Archived-At: 
 <https://www.postgresql.org/message-id/39945.1650895508%40sss.pgh.pa.us>
Precedence: bulk

Alvaro Herrera <alvherre@alvh.no-ip.org> writes:
> Hmm, so 027_stream_regress.pl is not prepared to deal with any unlogged
> tables that may be left in the regression database (which is what my
> spgist addition did).  I first tried doing a TRUNCATE of the unlogged
> table, but that doesn't work either, and it turns out that the
> regression database does not have any UNLOGGED relations.  Maybe that's
> something we need to cater for, eventually, but for now dropping the
> table suffices.  I have pushed that.

It does seem like the onus should be on 027_stream_regress.pl to
deal with that, rather than restricting what the core tests can
leave behind.

Maybe we could have it look for unlogged tables and drop them
before making the dumps?  Although I don't understand why
TRUNCATE wouldn't do the job equally well.

			regards, tom lane