Re: Issues with ON CONFLICT UPDATE and REINDEX CONCURRENTLY

Hi,

On 2025-Nov-27, Mihail Nikalayeu wrote:

> On Wed, Nov 26, 2025 at 7:34 PM Álvaro Herrera <alvherre(at)kurilemu(dot)de> wrote:
> > We ran into one more problem with the new test, evidenced by timeouts by
> > buildfarm member prion. For CATCACHE_FORCE_RELEASE builds on two of the
> > tests, we get a few invalidations of the catalog snapshot ahead of what
> > we expect, and because we have an injection point to sleep there, those
> > tests get stuck.
>
> Oh, I missed that. Non-yet pushed tests are probably affected too.

Yeah, I suspect as much.

> > Here's one possible fix.
>
> I have tried to move the setup of invalidate-catalog-snapshot-end to
> s1_start_upsert as the first command - but for some reason it wasn't
> working the way I expected. But maybe I missed something.

Right, this is why I said that this is one possible fix. I mean, maybe
there are other ways to fix it. I'm not sure it's the simplest or the
most robust, but I don't want to spend too much time looking for other
ways either.

> Solution seems reasonable to me, another related ideas:
> * replace "select case when" with function like
> injection_points_wakeup_if_waiting to avoid the possible race between
> select and wake up (but AFAIK it is not possible in the current case)
> * introduce some injection_points function to enter "ignore all runs,
> but still allowed to attach/detach" mode and "normal" mode.. As first
> command of setup - enter such "setup mode", as last - back to normal.

Ah, I had thought about the first one of these ideas, but not the second
one. I noted both in the commit message, in case somebody is motivated
to implement them.

Thanks for reviewing. I have pushed it now. Looking at the next one.

--
Álvaro Herrera PostgreSQL Developer — https://www.EnterpriseDB.com/
"Having your biases confirmed independently is how scientific progress is
made, and hence made our great society what it is today" (Mary Gardiner)