postgres-timescaledb creates its extension twice now: through the site_init exec it has always had, and through the extensions declaration added in #10. Both are idempotent so nothing breaks, but the exec is the weaker of the two, it fires once per project at lerd env time and names only the app database, so it never reached the testing one and a snapshot restore took the extension away again.
It stays for now on purpose. Presets reach installed users within a day while binaries do not, so removing it before the lerd release that understands extensions would leave timescale sites with neither mechanism.
Once that release is out and has had a version or two to spread, the site_init block can go. Nothing else in the preset depends on it.
postgres-timescaledb creates its extension twice now: through the site_init exec it has always had, and through the extensions declaration added in #10. Both are idempotent so nothing breaks, but the exec is the weaker of the two, it fires once per project at lerd env time and names only the app database, so it never reached the testing one and a snapshot restore took the extension away again.
It stays for now on purpose. Presets reach installed users within a day while binaries do not, so removing it before the lerd release that understands extensions would leave timescale sites with neither mechanism.
Once that release is out and has had a version or two to spread, the site_init block can go. Nothing else in the preset depends on it.