Horton

Re: Assert triggered during RE_compile_and_cache

Mark Dilger <mark.dilger@enterprisedb.com>

View thread View on postgr.es
From: Mark Dilger <mark.dilger@enterprisedb.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: PostgreSQL-development <pgsql-hackers@postgresql.org>
Date: 2021-08-05T22:22:57Z
Lists: pgsql-hackers

Attachments


> On Aug 5, 2021, at 3:15 PM, Tom Lane <tgl@sss.pgh.pa.us> 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 then has the {0} or {0,0} applied to it.

You can find lots of cases using the attached regex generating script I whipped up for testing your work.  (Note this is just a quick and dirty tool for hacking, not anything refined.)

Commits

  1. Check the size in COPY_POINTER_FIELD

  2. Rethink regexp engine's backref-related compilation state.

  3. Fix use-after-free issue in regexp engine.

  4. Make regexp engine's backref-related compilation state more bulletproof.

  5. Really fix the ambiguity in REFRESH MATERIALIZED VIEW CONCURRENTLY.

  6. Avoid generating extra subre tree nodes for capturing parentheses.