Re: A test for replay of regression tests

On Fri, Dec 10, 2021 at 10:36 AM Andres Freund <andres@anarazel.de> wrote:
> Seems like we ought to add a tiny tap test or such for this - otherwise we
> won't have any coverage of "normal" tablespaces? I don't think they need to be
> exercised as part of the normal tests, but having some very basic testing
> in a tap test seems worthwhile.

Good idea, that was bothering me too.  Done.

> > -             print $conf "max_connections = 10\n";
> > +             print $conf "max_connections = 25\n";

> What's the relation of this to the rest?

Someone decided that allow_streaming should imply max_connections =
10, but we need ~20 to run the parallel regression test schedule.
However, I can just as easily move that to a local adjustment in the
TAP test file.  Done, like so:

+$node_primary->adjust_conf('postgresql.conf', 'max_connections', '25', 1);

> Absurd nitpick: What's the deal with using "" for one part, and '' for the
> rest?

Fixed.

> Separately: I think the case of seeing diffs will be too hard to debug like
> this, as the difference isn't shown afaict?

Seems to be OK.  The output goes to
src/test/recovery/tmp_check/log/regress_log_027_stream_regress, so for
example if you comment out the bit that deals with SEQUENCE caching
you'll see:

# Running: pg_dump -f
/usr/home/tmunro/projects/postgresql/src/test/recovery/primary.dump
--no-sync -p 63693 regression
ok 2 - dump primary server
# Running: pg_dump -f
/usr/home/tmunro/projects/postgresql/src/test/recovery/standby.dump
--no-sync -p 63694 regression
ok 3 - dump standby server
# Running: diff
/usr/home/tmunro/projects/postgresql/src/test/recovery/primary.dump
/usr/home/tmunro/projects/postgresql/src/test/recovery/standby.dump
436953c436953
< SELECT pg_catalog.setval('public.clstr_tst_s_rf_a_seq', 32, true);
---
> SELECT pg_catalog.setval('public.clstr_tst_s_rf_a_seq', 33, true);
... more hunks ...

And from the previous email:

On Fri, Dec 10, 2021 at 10:35 AM Thomas Munro <thomas.munro@gmail.com> wrote:
> On Fri, Dec 10, 2021 at 8:38 AM Andres Freund <andres@anarazel.de> wrote:
> > Personally I'd rather put relative tablespaces into a dedicated directory or
> > just into pg_tblspc, but without a symlink. Some tools need to understand
> > tablespace layout etc, and having them in a directory that, by the name, will
> > also contain other things seems likely to cause confusion.

Ok, in this version I have a developer-only GUC
allow_in_place_tablespaces instead.  If you turn it on, you can do:

CREATE TABLESPACE regress_blah LOCATION = '';

... and then pg_tblspc/OID is created directly as a directory.  Not
allowed by default or documented.