Re: "ERROR: could not open relation with OID 16391" error was encountered when reindexing

From: Michael Paquier <michael(at)paquier(dot)xyz>
To: feichanghong <feichanghong(at)qq(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Aleksander Alekseev <aleksander(at)timescale(dot)com>, pgsql-hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: "ERROR: could not open relation with OID 16391" error was encountered when reindexing
Date: 2024-01-19 05:26:54
Message-ID: ZaoIHhxdXmMqahe5@paquier.xyz
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, Jan 17, 2024 at 04:03:46PM +0800, feichanghong wrote:
> It has been verified that the patch in the attachment can solve the
> above problems. I sincerely look forward to your suggestions!

Thanks for the patch. I have completely forgotten to update this
thread. Except for a few comments and names that I've tweaked, this
was OK, so applied and backpatched after splitting things into two:
- One commit for try_index_open().
- Second commit for the fix in reindex_index().

I've looked at the concurrent paths as well, and even if these involve
more relations opened we maintain a session lock on the parent
relations that we manipulate, so I could not see a pattern where the
index would be dropped and where we'd try to open it. Now, there are
cases where it is possible to deadlock for the concurrent paths, but
that's not new: schema or database level reindexes can also hit that.

This is one of these areas where tests are hard to write now because
we want to stop operations at specific points but we cannot.
--
Michael

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message John Naylor 2024-01-19 05:28:28 Re: generate syscache info automatically
Previous Message Michael Paquier 2024-01-19 05:20:31 Re: [PATCH] Add additional extended protocol commands to psql: \parse and \bindx