From: Tom Lane <tgl@sss.pgh.pa.us>
To: Mark Dilger <mark.dilger@enterprisedb.com>
cc: PostgreSQL-development <pgsql-hackers@postgresql.org>
Subject: Re: Assert triggered during RE_compile_and_cache
In-reply-to: <29C525E6-A912-459F-BE27-217F25F76B5E@enterprisedb.com>
References: <0203588E-E609-43AF-9F4F-902854231EE7@enterprisedb.com>
 <7F9BFA6F-9BC6-4A27-BFA1-2F01682BD644@enterprisedb.com>
 <2426993.1628201727@sss.pgh.pa.us>
 <29C525E6-A912-459F-BE27-217F25F76B5E@enterprisedb.com>
Comments: In-reply-to Mark Dilger <mark.dilger@enterprisedb.com>
	message dated "Thu, 05 Aug 2021 15:22:57 -0700"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <2437329.1628205382.1@sss.pgh.pa.us>
Content-Transfer-Encoding: quoted-printable
Date: Thu, 05 Aug 2021 19:16:22 -0400
Message-ID: <2437330.1628205382@sss.pgh.pa.us>
Archived-At: 
 <https://www.postgresql.org/message-id/2437330.1628205382%40sss.pgh.pa.us>
Precedence: bulk

Mark Dilger <mark.dilger@enterprisedb.com> writes:
> I have now found lots of cases of this failure.  I *believe* the backref=
erence 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 pre-v14 branches.  That means it's some bug introduced in
the performance improvements I did a few months ago.  Open item added.

			regards, tom lane