From: Tom Lane <tgl@sss.pgh.pa.us>
To: Robert Haas <robertmhaas@gmail.com>
cc: Andrew Dunstan <andrew@dunslane.net>,
        Thomas Munro <thomas.munro@gmail.com>,
        pgsql-hackers <pgsql-hackers@postgresql.org>
Subject: Re: Query execution in Perl TAP tests needs work
In-reply-to: <CA+TgmoYZ9PKmmv3e3kF=p47ikaHNsGshhZf-R79b+vnXhSW0Tw@mail.gmail.com>
References: <CA+hUKGJoEO33K=ZynsH=xkiEyfBMZjOoqBK+gouBdTGW2-woig@mail.gmail.com> <4f3038c7-2b37-2625-c4c6-ebf7cbcb076d@dunslane.net> <be64907d-48db-1145-7749-0f2dcf9a5256@dunslane.net> <CA+hUKGKz715tkYFmS12fxqxWG1o9=8y3TTo2uYdGLO=EPm=BUw@mail.gmail.com> <05341dc0-a5c3-f631-35e3-54235cfed774@dunslane.net> <CA+TgmoYZ9PKmmv3e3kF=p47ikaHNsGshhZf-R79b+vnXhSW0Tw@mail.gmail.com>
Comments: In-reply-to Robert Haas <robertmhaas@gmail.com>
	message dated "Wed, 18 Oct 2023 10:03:06 -0400"
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-ID: <3111322.1697639279.1@sss.pgh.pa.us>
Content-Transfer-Encoding: quoted-printable
Date: Wed, 18 Oct 2023 10:27:59 -0400
Message-ID: <3111323.1697639279@sss.pgh.pa.us>
Archived-At: <https://www.postgresql.org/message-id/3111323.1697639279%40sss.pgh.pa.us>
Precedence: bulk

Robert Haas <robertmhaas@gmail.com> writes:
> On Sat, Sep 2, 2023 at 2:42=E2=80=AFPM Andrew Dunstan <andrew@dunslane.n=
et> wrote:
>>> How much burden is it? Would anyone actually mind?

> ... At the same time, fallbacks can be a problem too,
> because then you can end up with things that work one way on one
> developer's machine (or BF machine) and another way on another
> developer's machine (or BF machine) and it's not obvious that the
> reason for the difference is that one machine is using a fallback and
> the other is not.

I agree with this worry.

> In terms of what that faster and better thing might be, AFAICS, there
> are two main options. First, we could proceed with the approach you've
> tried here, namely requiring everybody to get Platypus::FFI. I find
> that it's included in MacPorts on my machine, which is at least
> somewhat of a good sign that perhaps this is fairly widely available.

I did a bit of research on this on my favorite platforms, and did
not like the results:

RHEL8: does not seem to be packaged at all.

Fedora 37: available, but the dependencies are a bit much:

$ sudo yum install perl-FFI-Platypus
Last metadata expiration check: 2:07:42 ago on Wed Oct 18 08:05:40 2023.
Dependencies resolved.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D
 Package                 Architecture Version               Repository    =
 Size
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D
Installing:
 perl-FFI-Platypus       x86_64       2.08-1.fc37           updates       =
417 k
Installing dependencies:
 libgfortran             x86_64       12.3.1-1.fc37         updates       =
904 k
 libquadmath             x86_64       12.3.1-1.fc37         updates       =
206 k
 libquadmath-devel       x86_64       12.3.1-1.fc37         updates       =
 48 k
 perl-FFI-CheckLib       noarch       0.29-2.fc37           updates       =
 29 k
Installing weak dependencies:
 gcc-gfortran            x86_64       12.3.1-1.fc37         updates       =
 12 M

Transaction Summary
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D
Install  6 Packages

Total download size: 14 M
Installed size: 37 M
Is this ok [y/N]: =


gfortran?   Really??  I mean, I don't care about the disk space,
but this is not promising for anyone who has to build it themselves.

So I'm afraid that requiring Platypus::FFI might be a bridge too
far for a lot of our older buildfarm machines.

> Another thing, also already mentioned, that we can do is cache psql
> connections instead of continuously respawing psql.

This seems like it's worth thinking about.  I agree with requiring
the re-use to be explicit within a TAP test, else we might have
mysterious behavioral changes (akin to connection-pooler-induced
bugs).

			regards, tom lane