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.
Date: Mon, 11 Mar 2024 16:15:39 -0400
Message-ID: <1547879.1710188139@sss.pgh.pa.us> (raw)
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>
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
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-committers@postgresql.org
Cc: tgl@sss.pgh.pa.us, pgsql@j-davis.com, pgsql-committers@lists.postgresql.org
Subject: Re: pgsql: Catalog changes preparing for builtin collation provider.
In-Reply-To: <1547879.1710188139@sss.pgh.pa.us>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox