Re: Adding "large" to PG_TEST_EXTRA

Поиск
Список
Период
Сортировка
От Stephen Frost
Тема Re: Adding "large" to PG_TEST_EXTRA
Дата
Msg-id Y+qMTPD612KvT7OQ@tamriel.snowman.net
обсуждение исходный текст
Ответ на Re: Adding "large" to PG_TEST_EXTRA  (Andres Freund <andres@anarazel.de>)
Ответы Re: Adding "large" to PG_TEST_EXTRA  (Andres Freund <andres@anarazel.de>)
Список pgsql-hackers
Greetings,

* Andres Freund (andres@anarazel.de) wrote:
> On 2023-02-13 13:45:41 -0500, Stephen Frost wrote:
> > Are there existing tests that we should add into that set that you're
> > thinking of..?  I've been working with the Kerberos tests and that's
> > definitely one that seems to fit this description...
>
> I think the kerberos tests are already opt-in, so I don't think we need to
> gate it further.

I'd like to lump them in with a bunch of other tests though, to give it
more chance to run..  My issue currently is that they're *too* gated.

> Maybe the pgbench tests?

Sure.

> I guess there's an argument to be made that we should use this for e.g.
> 002_pg_upgrade.pl or 027_stream_regress.pl - but I think both of these test
> pretty fundamental behaviour like WAL replay, which is unfortunately is pretty
> easy to break, so I'd be hesitant.

Hm.  If you aren't playing with that part of the code though, maybe it'd
be nice to not run them.  The pg_dump tests might also make sense to
segregate out as they can add up to be a lot, and there's more that we
could and probably should be doing there.

> I guess we could stop running the full regression tests in 002_pg_upgrade.pl
> if !large?

Perhaps... but then what are we testing?

Thanks,

Stephen

Вложения

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Andres Freund
Дата:
Сообщение: Re: Adding "large" to PG_TEST_EXTRA
Следующее
От: Andres Freund
Дата:
Сообщение: Re: Adding "large" to PG_TEST_EXTRA