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(at)leadboat(dot)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, need a 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(at)postgresql(dot)org to propose an out-of-cycle release.