On Tue, Aug 29, 2023 at 1:48 PM Noah Misch <noah(at)leadboat(dot)com> wrote:
> On Mon, Aug 28, 2023 at 05:29:56PM +1200, Thomas Munro wrote:
> > 1. Don't fork anything at all: open (and cache) a connection directly
> > from Perl.
> > 1a. Write xsub or ffi bindings for libpq. Or vendor (parts) of the
> > popular Perl xsub library?
> > 1b. Write our own mini pure-perl pq client module. Or vendor (parts)
> > of some existing one.
> > 2. Use long-lived psql sessions.
> > 2a. Something building on BackgroundPsql.
> > 2b. Maybe give psql or a new libpq-wrapper a new low level stdio/pipe
> > protocol that is more fun to talk to from Perl/machines?
>
> (2a) seems adequate and easiest to achieve. If DBD::Pg were under a
> compatible license, I'd say use it as the vendor for (1a). Maybe we can get
> it relicensed? Building a separate way of connecting from Perl would be sad.
Here's my minimal POC of 2a. It only changes ->safe_psql() and not
the various other things like ->psql() and ->poll_query_until().
Hence use of amcheck/001_verify_heapam as an example: it runs a lot of
safe_psql() queries. It fails in all kinds of ways if enabled
generally, which would take some investigation (some tests require
there to be no connections at various times, so we'd probably need to
insert disable/re-enable calls at various places).