Re: Query execution in Perl TAP tests needs work - Mailing list pgsql-hackers

From Thomas Munro
Subject Re: Query execution in Perl TAP tests needs work
Date
Msg-id CA+hUKGJWf2uYQQW=ox6vY+tu1QWb55A42U4se2NK9iCXnx42ig@mail.gmail.com
Whole thread Raw
In response to Re: Query execution in Perl TAP tests needs work  (Noah Misch <noah@leadboat.com>)
List pgsql-hackers
On Tue, Aug 29, 2023 at 1:48 PM Noah Misch <noah@leadboat.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).

Attachment

pgsql-hackers by date:

Previous
From: Michael Paquier
Date:
Subject: Re: Autogenerate some wait events code and documentation
Next
From: Heikki Linnakangas
Date:
Subject: Re: Use FD_CLOEXEC on ListenSockets (was Re: Refactoring backend fork+exec code)