| From: | Aleksander Alekseev <aleksander(at)timescale(dot)com> |
|---|---|
| To: | PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
| Cc: | Michael Paquier <michael(at)paquier(dot)xyz>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>, Craig Ringer <craig(at)2ndquadrant(dot)com>, Craig Ringer <craig(dot)ringer(at)enterprisedb(dot)com> |
| Subject: | Re: [PATCH] We install pg_regress and isolationtester but not pg_isolation_regress |
| Date: | 2021-04-28 09:44:45 |
| Message-ID: | CAJ7c6TOC_LpKd-4GFZ7J=mPtPgh7G8=PbBzHBhw0mAnQVu=UiQ@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Hi hackers,
> Any opinions on backpatching?
> Other than src/test/modules/brin, the ISOLATION users don't look
> much like real extensions (rather than test scaffolding), either.
> Out of core, the only thing I can see with isolation tests is rum, but
> it uses a workaround to have an access to the necessary binaries.
I just wanted to let you know that TimescaleDB uses
pg_isolation_regress and occasionally there are reports from some
suffering/puzzled users/developers, e.g. [1]. Not 100% sure if it
makes investing the time into backpatching worth it. However if
someone could do it, it would be nice.
[1]: https://github.com/timescale/timescaledb/issues/1655
--
Best regards,
Aleksander Alekseev
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Antonin Houska | 2021-04-28 10:14:56 | Re: Built-in connection pooler |
| Previous Message | Amit Kapila | 2021-04-28 09:39:00 | Re: Replication slot stats misgivings |