Horton

Re: scalability bottlenecks with (many) partitions (and more)

Tom Lane <tgl@sss.pgh.pa.us>

View thread
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>
Date: 2025-03-04T22:49:57Z
Lists: pgsql-hackers

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. Make FP_LOCK_SLOTS_PER_BACKEND look like a function

  2. Fix asserts in fast-path locking code

  3. Increase the number of fast-path lock slots

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 = "$tmp_loc/$install_dir";
 		$bindir = "$tmp_loc/bin";
-		$libdir = "$tmp_loc/lib/postgresql";
+		$libdir = "$tmp_loc/lib";
+		$libdir .= '/postgresql' unless $libdir =~ /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 = "$tmp_loc/$install_dir";
 		$bindir = "$tmp_loc/bin";
-		$libdir = "$tmp_loc/lib/postgresql";
+		$libdir = "$tmp_loc/lib";
+		$libdir .= '/postgresql' unless $libdir =~ /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='/Users/buildfarm/bf-data/HEAD/pgsql.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