MIME-Version: 1.0
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>
In-Reply-To: <05341dc0-a5c3-f631-35e3-54235cfed774@dunslane.net>
From: Robert Haas <robertmhaas@gmail.com>
Date: Wed, 18 Oct 2023 10:03:06 -0400
Message-ID: <CA+TgmoYZ9PKmmv3e3kF=p47ikaHNsGshhZf-R79b+vnXhSW0Tw@mail.gmail.com>
Subject: Re: Query execution in Perl TAP tests needs work
To: Andrew Dunstan <andrew@dunslane.net>
Cc: Thomas Munro <thomas.munro@gmail.com>, pgsql-hackers <pgsql-hackers@postgresql.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://www.postgresql.org/message-id/CA%2BTgmoYZ9PKmmv3e3kF%3Dp47ikaHNsGshhZf-R79b%2BvnXhSW0Tw%40mail.gmail.com>
Precedence: bulk

On Sat, Sep 2, 2023 at 2:42=E2=80=AFPM Andrew Dunstan <andrew@dunslane.net>=
 wrote:
> I confess I'm a little reluctant to impose this burden on buildfarm owner=
s. We should think about some sort of fallback in case this isn't supported=
 on some platform, either due to technological barriers or buildfarm owner =
reluctance.

How much burden is it? Would anyone actually mind?

I definitely don't want to put ourselves in a situation where we add a
bunch of annoying dependencies that are required to be able to run the
tests, not just because it will inconvenience buildfarm owners, but
also because it will potentially inconvenience developers, and in
particular, me. 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 feel like this tends to create so much aggravation
in practice that it's best not to have fallbacks in this kind of
situation - my vote is that we either stick with the current method
and live with the performance characteristics thereof, or we put in
place something that is faster and better and that new thing becomes a
hard dependency for anyone who wants to be able to run the TAP tests.

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.
That might need more investigation, though. Second, we could write a
pure-Perl implementation, as you proposed earlier. That would be more
work to write and maintain, but would avoid needing FFI. Personally, I
feel like either an FFI-based approach or a pure-Perl approach would
be pretty reasonable, as long as Platypus::FFI is widely
available/usable. If we go with pure Perl, the hard part might be
managing the authentication methods, but as Thomas pointed out to me
yesterday, we now have UNIX sockets on Windows, and thus everywhere,
so maybe we could get to a point where the pure-Perl implementation
wouldn't need to do any non-trivial authentication.

Another thing, also already mentioned, that we can do is cache psql
connections instead of continuously respawing psql. That doesn't
require any fundamentally new mechanism, and in some sense it's
independent of the approaches above, because they could be implemented
without caching connections, but they would benefit from caching
connections, as the currently psql-based approach also does. I think
it would be good to introduce new syntax for this, e.g.:

$conn_primary =3D $node_primary->connect();
$conn_primary->simple_query('whatever');
$conn_primary->simple_query('whatever 2');
$conn_primary->disconnect();

Something like this would require a fairly large amount of mechanical
work to implement across all of our TAP test cases, but I think it
would be effort well spent. If we try to introduce connection caching
"transparently," I think it will turn into another foot-gun that
people keep getting wrong because they don't realize there is magic
under the hood, or forget how it works.

--=20
Robert Haas
EDB: http://www.enterprisedb.com