Subject: Re: Query execution in Perl TAP tests needs work

From: Robert Haas <[email-masked]>
Date: Wed, 18 Oct 2023 10:03:06 -0400

On Sat, Sep 2, 2023 at 2:42 PM Andrew Dunstan <[email-masked]> wrote:
> I confess I'm a little reluctant to impose this burden on buildfarm owners. 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 = $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.

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

---

From: Tom Lane <[email-masked]>
Date: Wed, 18 Oct 2023 10:27:59 -0400

> ... At the same time, fallbacks can be a problem too,
> the other is not.

I agree with this worry.

> 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.
================================================================================
 Package                 Architecture Version               Repository     Size
================================================================================
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
================================================================================
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.

> 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

---

From: Robert Haas <[email-masked]>
Date: Wed, 18 Oct 2023 11:41:28 -0400

> I did a bit of research on this on my favorite platforms, and did

Hmm. That's unfortunate. Is perl -MCPAN -e 'install Platypus::FFI' a
viable alternative?

---

From: Tom Lane <[email-masked]>
Date: Wed, 18 Oct 2023 11:47:17 -0400

> Hmm. That's unfortunate. Is perl -MCPAN -e 'install Platypus::FFI' a

Probably, see my followup.

			regards, tom lane