On Mon, Apr 25, 2022 at 10:05:08AM -0400, Tom Lane wrote:
> 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.
Yeah. Using "pg_dumpall --no-unlogged-table-data", as attached, suffices.
> 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.
After TRUNCATE, one still gets a setval for sequences and a zero-row COPY for
tables. When dumping a standby or using --no-unlogged-table-data, those
commands are absent.
