Re: CREATE INDEX CONCURRENTLY does not index prepared xact's data

On Sun, Aug 08, 2021 at 04:31:07PM +0500, Andrey Borodin wrote:
> > 8 авг. 2021 г., в 03:19, Noah Misch <noah@leadboat.com> написал(а):
> > On Sun, Aug 08, 2021 at 12:00:55AM +0500, Andrey Borodin wrote:
> >> Changes:
> >> 1. Added assert in step 2 (fix for missed invalidation message). I wonder how deep possibly could be
RelationBuildDesc()inside RelationBuildDesc() inside RelationBuildDesc() ... ? If the depth is unlimited we, probably,
needa better data structure.
 
> > 
> > I don't know either, hence that quick data structure to delay the question.
> > debug_discard_caches=3 may help answer the question.  RelationBuildDesc()
> > reads pg_constraint, which is !rd_isnailed.  Hence, I expect one can at least
> > get RelationBuildDesc("pg_constraint") inside RelationBuildDesc("user_table").
> I've toyed around with
> $node->append_conf('postgresql.conf', 'debug_invalidate_system_caches_always = 3'); in test.
> I had failures only at most with
> Assert(in_progress_offset < 4);
> See [0] for stack trace. But I do not think that it proves that deeper calls are impossible with other DB schemas.

I didn't find the [0] link in your message; can you send it again?  I suspect
no rel can appear more than once in the stack, and all but one rel will be a
system catalog.  That said, dynamically growing the array is reasonable, even
if a small maximum depth theoretically exists.

> Step 1. Test for CIC with regular transactions.
> Step 2. Fix
> Step 3. Test for CIC with 2PC
> Step 4. Part of the fix that I'm sure about
> Step 5. Dubious part of fix...

> How to you think, do we have a chance to fix things before next release on August 12th?

No.  At a minimum, we still need to convince ourselves that step 5 is correct.
Even if that were already done, commits to released branches get more cautious
in the few days before the wrap date (tomorrow).  Once it's committed, you
could contact pgsql-release@postgresql.org to propose an out-of-cycle release.