Re: Issues with ON CONFLICT UPDATE and REINDEX CONCURRENTLY - Mailing list pgsql-hackers

From Michail Nikolaev
Subject Re: Issues with ON CONFLICT UPDATE and REINDEX CONCURRENTLY
Date
Msg-id CANtu0oixyt18rrZXNkMNKghgvs_1xHs5RovBmOhXF5K8J-9PuA@mail.gmail.com
Whole thread Raw
In response to Re: Issues with ON CONFLICT UPDATE and REINDEX CONCURRENTLY  (Michael Paquier <michael@paquier.xyz>)
Responses Re: Issues with ON CONFLICT UPDATE and REINDEX CONCURRENTLY
List pgsql-hackers
Hello, Michael!

> This is a non-fresh Friday-afternoon idea, but it would make sure that
> we don't have any transactions using the indexes switched to _ccold
> with indisvalid that are waiting for a drop in phase 5.  Your tests
> seem to pass with that, and that keeps the operation intact
> concurrent-wise (I'm really wishing for isolation tests with injection
> points just now, because I could use them here).

Yes, I also have tried that approach, but it doesn't work, unfortunately.
You may fail test increasing number of connections:

'--no-vacuum --client=10 -j 2 --transactions=1000',

The source of the issue is not the swap of the indexes (and not related to REINDEX CONCURRENTLY only), but the fact that indexes are fetched once during planning (to find the arbiter), but then later reread with a new catalog snapshot for the the actual execution.

So, other possible fixes I see:
* fallback to replanning in case we see something changed during the execution
* select arbiter indexes during actual execution

> That's a HEAD-only thing IMO,
> though.
Do you mean that it needs to be moved to a separate patch?

Best regards,
Mikhail.

pgsql-hackers by date:

Previous
From: Jelte Fennema-Nio
Date:
Subject: libpq: Fix lots of discrepancies in PQtrace
Next
From: Markus Winand
Date:
Subject: Re: ON ERROR in json_query and the like