Robert Haas <robertmhaas@gmail.com> writes:
> On Sat, Sep 2, 2023 at 2:42 PM Andrew Dunstan <andrew@dunslane.net> 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.
================================================================================
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.
> 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