On Sat, 1 Mar 2025 at 03:42, Sami Imseih wrote:
> I was running "make check-world" this morning on a machine that has an
> old version of perl, 5.16, and the check-world was hung on
> /usr/bin/perl t/002_pg_upgrade.pl.
>
FWIW, both massasauga / snakefly were stuck owing to this for the past few
Sami Imseih writes:
>> Just noting here that \s{1} is simply the same as /s
> Correct. But I do like the explicitness of it though.
Yeah. I like mine better though because it's not dependent
on the amount of whitespace at the start of the line.
regards, tom lane
> After a bit of fooling around I found that using an explicit \n
> instead of ^ fixes it. Not the world's most idiomatic regex,
> but it'll do. Will push the attached shortly.
I can also confirm this works as expected, although I feel my
suggested expression [0] is easier to understand, but I h
>
>
>
> Just noting here that \s{1} is simply the same as /s
Correct. But I do like the explicitness of it though.
—
Sami
>
On 2025-02-28 Fr 2:29 PM, Sami Imseih wrote:
My perl expertise is bit shallow, but I could not find much
regarding bugs related to such behavior, or maybe I did not
look enough.
Playing around with this, "s+", "s{1,}", s{2,}" all of these combinations
where we are searching for more than 1 spa
I was running "make check-world" this morning on a machine that has an
old version of perl, 5.16, and the check-world was hung on
/usr/bin/perl t/002_pg_upgrade.pl.
I never saw "make check-world" hang on this old version of perl,
but I bisected the regression to this commit fc0d0ce978752493,
the s
Sami Imseih writes:
> repro'd. I don't want to attach the file here, but I added a cp
> to get the dump file somewhere local
Thanks for the tips about an efficient repro. I installed 5.16.3
locally using perlbrew and was able to duplicate the problem.
After a bit of fooling around I found that u
My perl expertise is bit shallow, but I could not find much
regarding bugs related to such behavior, or maybe I did not
look enough.
Playing around with this, "s+", "s{1,}", s{2,}" all of these combinations
where we are searching for more than 1 space result in the hanging command,
but we really o
> I also tested the same regexp expression in isolation
> and I could not repro the issue. Will try a real dumpfile next.
>
repro'd. I don't want to attach the file here, but I added a cp
to get the dump file somewhere local
+++ b/src/bin/pg_upgrade/t/002_pg_upgrade.pl
@@ -326,10 +326,12 @@ $oldn
> 5.16 is still supported according to our install instructions,
> so let's see if we can adjust that regex so it works with 5.16.
> The first thing I'd try is
>
> - $dump =~ s {(^\s+'version',) '\d+'::integer,$}
> + $dump =~ s {^(\s+'version',) '\d+'::integer,$}
>
With the diff below,
Sami Imseih writes:
> I was running "make check-world" this morning on a machine that has an
> old version of perl, 5.16, and the check-world was hung on
> /usr/bin/perl t/002_pg_upgrade.pl.
Interesting!
> and specifically, the process hangs with this specific change.
> - $dump =~ s ['ver
On Sat, 2025-02-22 at 21:48 -0500, Tom Lane wrote:
> CREATE INDEX vcharidx ON vchartmp USING GIST ( text(a) );
>
> The index column will be given the name "text". However, it
> dumps as
>
> CREATE INDEX vcharidx ON public.vchartmp USING gist (((a)::text));
Thank you! I dismissed the naming issu
Andrew Dunstan writes:
> On 2025-02-22 Sa 9:20 PM, Tom Lane wrote:
>> I'm not really seeing a better answer than hacking the comparison
>> rules to ignore the relallvisible difference for these tables.
>> That's darn ugly, and I suspect the implementation will be messy,
>> but do we have another w
On 2025-02-22 Sa 9:20 PM, Tom Lane wrote:
I wrote:
Furthermore, it can't be a coincidence that the four tables we are
seeing relallvisible diffs for are exactly the four tables in the
regression database that have hash indexes.
Oh! If the source version is <= 9.6, old_9_6_invalidate_hash_inde
Jeff Davis writes:
> It's also strange that copperhead is consistently failing on 12 with:
> pg_restore: while PROCESSING TOC:
> pg_restore: from TOC entry 4163; 0 0 STATISTICS DATA "vcharidx" (no
> owner)
> pg_restore: error: could not execute query: ERROR: column "text" of
> relation "vc
I wrote:
> Furthermore, it can't be a coincidence that the four tables we are
> seeing relallvisible diffs for are exactly the four tables in the
> regression database that have hash indexes.
Oh! If the source version is <= 9.6, old_9_6_invalidate_hash_indexes()
generates a script "reindex_hash.s
On Sat, 2025-02-22 at 20:15 -0500, Tom Lane wrote:
> That's just crazy --- I would be
> unsurprised if a range of back releases were misbehaving in the same
> way, but not two isolated branches.
>
> Furthermore, it can't be a coincidence that the four tables we are
> seeing relallvisible diffs for
I wrote:
> So there's our extra round of ANALYZE right there. I diked out the
> vacuumdb call and things are working much better. It seems to pass
> for branches back through 9.3, and upgrade from 9.2 has only some
> diffs for relallvisible (see attached).
I confess that when I wrote that, I had
On 2025-02-22 Sa 1:34 PM, Tom Lane wrote:
Andrew Dunstan writes:
On 2025-02-21 Fr 10:11 PM, Tom Lane wrote:
... It seems there is
something different between what TestUpgradeXversion.pm is doing
and what 002_pg_upgrade.pl is doing. No clue what, although it
does look like an additional roun
Andrew Dunstan writes:
> On 2025-02-21 Fr 10:11 PM, Tom Lane wrote:
>> ... It seems there is
>> something different between what TestUpgradeXversion.pm is doing
>> and what 002_pg_upgrade.pl is doing. No clue what, although it
>> does look like an additional round of analyze'ing has added more
>>
On 2025-02-21 Fr 10:11 PM, Tom Lane wrote:
Jeff Davis writes:
In 002_pg_upgrade.pl, I disabled autovacuum and restarted after the
regression run. In other words, in the old cluster, autovacuum did have
a chance to run, just not after the first dumpall.
The hack I posted should prevent autova
On Fri, 2025-02-21 at 21:57 -0500, Tom Lane wrote:
> Hmm. I forced my local BF installation to run a v17-to-HEAD upgrade
> test, and it still failed, though seemingly with fewer diffs than
> the buildfarm is reporting for older branches. (Diffs attached for
> amusement's sake.) I don't believe w
On Fri, 2025-02-21 at 21:00 -0500, Tom Lane wrote:
> I think we might indeed want that, but it doesn't seem to be the
> explanation for the buildfarm failures, because the diffs look
> to be consistent across runs which you'd not expect from
> autovacuum-driven changes. I suspect that the problem
Jeff Davis writes:
> The version that I committed had the following change to
> 002_pg_upgrade.pl:
> # Stabilize stats before pg_dumpall.
> $oldnode->append_conf('postgresql.conf', 'autovacuum = off');
> $oldnode->restart;
> ...
> $newnode->append_conf('postgresql.conf', 'autovacuum =
On Fri, Feb 21, 2025 at 7:57 PM Jeff Davis wrote:
> I think we need a similar change in the buildfarm client's
> TestUpgradeXversion.pm? Is -hackers the right place to discuss that?
Yes, I believe -hackers is the right place to discuss that.
--
Robert Haas
EDB: http://www.enterprisedb.com
On Thu, 2025-02-20 at 13:17 -0800, Jeff Davis wrote:
> On Thu, 2025-02-20 at 18:30 +, Jeff Davis wrote:
> > Trial fix for old cross-version upgrades.
>
> That fixed one problem, but there are other problems with 9.2
> upgrades.
The version that I committed had the following change to
002_pg_u
On Thu, 2025-02-20 at 18:30 +, Jeff Davis wrote:
> Trial fix for old cross-version upgrades.
That fixed one problem, but there are other problems with 9.2 upgrades.
And it looks like there's also a problem with upgrades from 12.
Investigating...
Regards,
Jeff Davis
Trial fix for old cross-version upgrades.
Per buildfarm and reports, it seems that 9.X to 18 upgrades were
failing after commit 1fd1bd8710 due to an incorrect regex. Loosen the
regex to accommodate older versions.
Reported-by: vignesh C
Reported-by: Andrew Dunstan
Discussion:
https://postgr.es
28 matches
Mail list logo
