From: Tom Lane <tgl@sss.pgh.pa.us>
To: Jeff Davis <pgsql@j-davis.com>
cc: pgsql-committers@lists.postgresql.org
Subject: Re: pgsql: Catalog changes preparing for builtin collation provider.
In-reply-to: <0ef325fa06e7a1605c4e119c4ecb637c67e5fb4e.camel@j-davis.com>
References: <E1rj5WA-002z5V-WA@gemulon.postgresql.org>
 <8899c7c62b86370076110920686fd24863b69a01.camel@j-davis.com>
 <1222780.1710047108@sss.pgh.pa.us>
 <0ef325fa06e7a1605c4e119c4ecb637c67e5fb4e.camel@j-davis.com>
Comments: In-reply-to Jeff Davis <pgsql@j-davis.com>
	message dated "Mon, 11 Mar 2024 12:26:55 -0700"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <1547878.1710188139.1@sss.pgh.pa.us>
Date: Mon, 11 Mar 2024 16:15:39 -0400
Message-ID: <1547879.1710188139@sss.pgh.pa.us>
Archived-At: 
 <https://www.postgresql.org/message-id/1547879.1710188139%40sss.pgh.pa.us>
Precedence: bulk

Jeff Davis <pgsql@j-davis.com> writes:
> I found it. On perl 5.16.3 on a failing instance:
>    use strict;
>    die '"" does not match qr// before substitution' unless '' =~ qr//;
>    my $foo = ('|a|' =~ s/a//r);
>    die '"" does not match qr// after substitution' unless '' =~ qr//;
>    print "$foo\n";
> dies with:
>    "" does not match qr// after substitution at - line 4.

Wow.

> That's so bizarre that I have to guess that it's a perl bug.

I agree.

> Assuming that it is a perl bug, there are two potential workarounds:
> 1. Use qr/^$/ for the test rather than qr//.
> 2. Don't use s/// anywhere. Find another way to transform devel
> versions into numbers.
> Either one has the potential to leave traps for later. New tests might
> either rely on s/// or expect qr// to work. I am inclined toward #1,
> because if we use qr/^$/, other tests are likely to copy it and they
> will be safe as well.

I like #1 as well, because qr// imposes zero constraints on what
the command's stderr is.  Checking qr/^$/ would express what we
really want to express, namely no stderr output.

> Though I'm still not sure what's going on with longfin.

Me too, not least because your minimal example fails just as above
with longfin's 5.14.0 build.  The fact that longfin nonetheless
passes the whole test indicates that something in between those
steps manages to clean up whatever the broken state is.

I also see that none of the other animals running 5.16.3 ever
showed the failure.  This could easily indicate some bizarre
platform-specificity in the bug.  It could also mean that the
Linux vendors started carrying patches for this bug, but the
three machines that failed are too old to have any such patch.
Digging in perl's revision history might be interesting if we
really felt the need to identify the bug precisely, but I don't.
Let's just go with your #1.

			regards, tom lane