From: Tom Lane <tgl@sss.pgh.pa.us>
To: Andrew Dunstan <andrew@dunslane.net>
cc: Andres Freund <andres@anarazel.de>, Tomas Vondra <tomas@vondra.me>,
        Jakub Wartak <jakub.wartak@enterprisedb.com>,
        Robert Haas <robertmhaas@gmail.com>,
        PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Subject: Re: scalability bottlenecks with (many) partitions (and more)
In-reply-to: <200085.1741127335@sss.pgh.pa.us>
References: <7c1eeafb-2375-4ff6-8469-0640d52d44ed@vondra.me> <ffiwtzc6vedo6wb4gbwelon5nefqg675t5c7an2ta7pcz646cg@qwmkdb3l4ett> <bfca1010-e5f1-4e36-a461-61b6aad60c47@vondra.me> <5xahykogf2sg3ofdqk2li7xx3t2vh23m42jnvfwxoi5fhh7iya@girlhoxdxjzc> <486baeb2-2adc-48d2-ba9d-13c4ae43301c@vondra.me> <vgtms7b5egxdypmknxpobocqton3puhprk3ahhk45rcx4uyl33@6uetxejsc75r> <733e72fa-5fc2-48fc-ab1f-1d8f1ab387c3@vondra.me> <d5499660-1541-4749-aff4-6be88be76d99@vondra.me> <nubyc3twqd7mtuyc2rbbt2yazjzbat6mlpfgxtb2ppv2egci3g@uvptf7xmh46m> <193453.1741123834@sss.pgh.pa.us> <qdvrgej743lcddjnb4lzyakt3f5bs2oz34r274wbmgc2g4474q@utqqrqiih65h> <197167.1741125678@sss.pgh.pa.us> <8a1a5c10-0644-4ea0-a9e8-73d3a2908e18@dunslane.net> <200085.1741127335@sss.pgh.pa.us>
Comments: In-reply-to Tom Lane <tgl@sss.pgh.pa.us>
	message dated "Tue, 04 Mar 2025 17:28:55 -0500"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <201791.1741128597.1@sss.pgh.pa.us>
Content-Transfer-Encoding: quoted-printable
Date: Tue, 04 Mar 2025 17:49:57 -0500
Message-ID: <201792.1741128597@sss.pgh.pa.us>
Archived-At: <https://www.postgresql.org/message-id/201792.1741128597%40sss.pgh.pa.us>
Precedence: bulk

Andrew Dunstan <andrew@dunslane.net> writes:
>> I think I found a logic bug. Testing.

Oh!  I bet you are looking at this 18-to-19 diff:

@@ -416,7 +416,8 @@ sub check_install_is_complete
 	{
 		$tmp_loc =3D "$tmp_loc/$install_dir";
 		$bindir =3D "$tmp_loc/bin";
-		$libdir =3D "$tmp_loc/lib/postgresql";
+		$libdir =3D "$tmp_loc/lib";
+		$libdir .=3D '/postgresql' unless $libdir =3D~ /postgres|pgsql/;
 		return (-d $bindir && -d $libdir);
 	}
 	elsif (-e "$build_dir/src/Makefile.global")    # i.e. not msvc
@@ -427,7 +428,8 @@ sub check_install_is_complete
 		chomp $suffix;
 		$tmp_loc =3D "$tmp_loc/$install_dir";
 		$bindir =3D "$tmp_loc/bin";
-		$libdir =3D "$tmp_loc/lib/postgresql";
+		$libdir =3D "$tmp_loc/lib";
+		$libdir .=3D '/postgresql' unless $libdir =3D~ /postgres|pgsql/;
 	}
 =

I'd dismissed that because sifaka isn't running in a directory
that has "postgres" or "pgsql" in its path, but just now I looked
at the logs of one of these steps, and guess where it's installing:

/usr/bin/make -C '../../../..' DESTDIR=3D'/Users/buildfarm/bf-data/HEAD/pg=
sql.build'/tmp_install install >'/Users/buildfarm/bf-data/HEAD/pgsql.build=
'/tmp_install/log/install.log 2>&1

I bet the "pgsql.build" name is confusing it into doing extra
installs.  This'd explain the impression I had that the test steps
were running a bit slower than they ought to.  If you check
sifaka's just-posted green run against its history, that run took
13:48 versus recent times of 10:35 or thereabouts, so we're definitely
eating a good deal of time someplace...

			regards, tom lane