> On Aug 8, 2021, at 10:34 AM, Mark Dilger wrote:
>
> I'll rerun my tests with the new master. I was still using the code that I
> pulled yesterday.
I am now testing REL_13_STABLE (ba9f665a4413f855bbf4b544481db326f7b9bd73) vs
master (c1132aae336c41cf9d316222e525d8d593c2b5d2). The regular
> On Aug 8, 2021, at 10:32 AM, Mark Dilger wrote:
>
> I'm not sure what you mean by "as-committed". Did you commit one of these
> recently?
Nevermind, I see the commit now.
I'll rerun my tests with the new master. I was still using the code that I
pulled yesterday.
—
Mark Dilger
Enterpr
> On Aug 8, 2021, at 10:29 AM, Tom Lane wrote:
>
> Mark Dilger writes:
>> Applying your to master changes
>> the outcome of some regular expression queries, but I *think* it changes
>> them for the better.
>
> [ squint... ] You sure you applied the patch properly? All these examples
> gi
Mark Dilger writes:
> Applying your to master changes
> the outcome of some regular expression queries, but I *think* it changes them
> for the better.
[ squint... ] You sure you applied the patch properly? All these examples
give me the same results in HEAD (with said patches as-committed) a
> On Aug 8, 2021, at 10:15 AM, Mark Dilger wrote:
>
> But these next two look to me correct before the patch and wrong after:
>
> select regexp_matches('ircecpbgyiggvtruqgxzigxzigxzisdbkuhbkuhrvl',
> '(((.)))(?:(\3))[^\f]');
> regexp_matches
>
> -(0 rows)
> + {g,g,g,g}
> +(
> On Aug 7, 2021, at 6:03 PM, Tom Lane wrote:
>
> That requires tweaking the API of parseqatom,
> which why I'd not done it like that to begin with --- but that's not
> a hard or complicated change, just a mite tedious.
>
> Hence, the attached patch.
Applying your to master changes the
out
> On Aug 8, 2021, at 9:31 AM, Tom Lane wrote:
>
> I realized that the earlier patch is actually a bad idea
Applying only your to master, the following
which did not crash begins to crash:
select regexp_split_to_array('rjgy', '(?:(.))((\1\1.))');
It also changes the results for anothe
I wrote:
> While this is sufficient to make the problem go away, I'm
> inclined to apply both changesets. Even if it accidentally
> works right now to have later backrefs consult the outer s/s2
> state pair rather than the original pair, that seems far too
> convoluted and bug-prone. The outer st
I wrote:
> ... What surprises me about this is not that
> crash, but that we didn't see fundamental breakage of backref-using
> patterns all over the place. It evidently breaks only in corner
> cases, but I'm not quite sure why the effects are so limited.
Ah-hah, I've sussed it. I'd supposed tha
I wrote:
>> Hm. I thought that this might be an old issue, but I'm not seeing the
>> crash in pre-v14 branches. That means it's some bug introduced in
>> the performance improvements I did a few months ago. Open item added.
> git bisect says the trouble started with
> ea1268f6301cc7adce571cc9c5
I wrote:
> Hm. I thought that this might be an old issue, but I'm not seeing the
> crash in pre-v14 branches. That means it's some bug introduced in
> the performance improvements I did a few months ago. Open item added.
git bisect says the trouble started with
ea1268f6301cc7adce571cc9c5ebe8d9
Mark Dilger writes:
> I have now found lots of cases of this failure. I *believe* the
> backreference is always greater than 1, and it is always in a capture group
> which then has the {0} or {0,0} applied to it.
Hm. I thought that this might be an old issue, but I'm not seeing the
crash in p
> On Aug 5, 2021, at 3:15 PM, Tom Lane wrote:
>
> I don't immediately see what's different about your failing case
> versus the not-failing ones.
I have now found lots of cases of this failure. I *believe* the backreference
is always greater than 1, and it is always in a capture group which
Mark Dilger writes:
> +select '' ~ '(())(\2){0}';
> +server closed the connection unexpectedly
> Any ideas?
Huh. This seems like some deficiency in the part of parseqatom
starting with
/* annoying special case: {0} or {0,0} cancels everything */
if (m == 0 && n == 0)
but I do
> On Aug 5, 2021, at 1:38 PM, Mark Dilger wrote:
>
> +select 'vyrlvyrlwvqko' ~ '(?:(?:((.((\2)\1.){0,0}?';
I've boiled it down a bit more:
+select '' ~ '()\1{0}';
+ ?column?
+--
+ t
+(1 row)
+
+select '' ~ '()(\1){0}';
+ ?column?
+--
+ t
+(1 row)
+
+select '' ~ '(())\2{
Tom,
while testing your patch in [1], I stumbled upon the following assert in
master, without your patch applied:
+select 'vyrlvyrlwvqko' ~ '(?:(?:((.((\2)\1.){0,0}?';
+server closed the connection unexpectedly
+ This probably means the server terminated abnormally
+ before or while proc
16 matches
Mail list logo
