Maksim Milyutin

Hmm, unfortunately it seems for PG 12 and 13 in docker container Travis CI job doesn't find `pg_isolation_regress` tool

> Hmm, unfortunately it seems for PG 12 and 13 in docker container Travis CI job doesn't find `pg_isolation_regress` tool This utility appeared in 14th version of postgres-alpine docker image....

> This utility appeared in 14th version of postgres-alpine docker image. Yes, distribution of `pg_isolation_regress` and dependent `isolationtester` utilities have started from PG14, in particular, in commit https://github.com/postgres/postgres/commit/2203ede9ae85b6423f850466122606275ea09b17 . But...

> My main concern is that these tests depend on timing of events. If the machine is temporarily lagging, they could fail. And this is totally possible in our buildfarm....

> How about polling pg_wait_sampling_profile until we get a reasonable count? At least we can sleep as long as necessary. I've rewritten isolation tests according your proposed manner. Please, review...

All tests have passed. @shinderuk please review this PR

> Previously we discussed an option of building PostgreSQL from source and manually installing pg_isolation_regress and isolationtester in a CI build. not PostgreSQL but just tools for isolation tests. >...

> Maybe we could build just these two binaries from source, but that doesn't make much difference. It takes much less time. > On Debian I can install postgresql-13 and...

@shinderuk I've enabled isolation tests just for pg14+ when extension is built separately from postgres contrib directory. PR is ready for review

Perhaps, it makes sense to refactor CI scripts, e.g., by joining static checking and test running builds leaving one build for each postgres version. @shinderuk please, investigate this possibility.