pg.ddx.io  pgsql-hackers@postgresql.org mailing list archive  
help / color / mirror / Atom feed
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
Date: Sun, 08 Aug 2021 12:31:53 -0400
Message-ID: <3168351.1628440313@sss.pgh.pa.us> (raw)
In-Reply-To: <2860330.1628384606@sss.pgh.pa.us>
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>
	<2437330.1628205382@sss.pgh.pa.us>
	<2442241.1628208783@sss.pgh.pa.us>
	<2822987.1628372679@sss.pgh.pa.us>
	<2860330.1628384606@sss.pgh.pa.us>

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 states should be strictly
> the concern of the iteration setup logic in the outer invocation
> of parseqatom.

> (I'm sort of wondering now whether the outer s/s2 states are
> even really necessary anymore ... maybe Spencer put those in
> as a way of preventing some prehistoric version of this bug.
> But I'm not excited about messing with that right now.)

I realized that the earlier patch is actually a bad idea, because
it breaks the possibility of updating the subre to mark it as
being referenced by a later backref, as the REG_NOSUB patch needs
to do.  However, on closer study, the outer s/s2 states being
added by the "prepare a general-purpose state skeleton" stanza
really are duplicative of the ones we already made for a
parenthesized atom, so we can just get rid of them.  Done that
way.

			regards, tom lane





view thread (17+ messages)  latest in thread

Message-ID: <3168351.1628440313@sss.pgh.pa.us>
Permalink:  ../3168351.1628440313@sss.pgh.pa.us/
Also on:    postgresql.org/message-id/3168351.1628440313@sss.pgh.pa.us

 · 

reply

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-hackers@postgresql.org
  Cc: tgl@sss.pgh.pa.us, mark.dilger@enterprisedb.com
  Subject: Re: Assert triggered during RE_compile_and_cache
  In-Reply-To: <3168351.1628440313@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