From: | Michael Paquier <michael(at)paquier(dot)xyz> |
---|---|
To: | Gurjeet Singh <gurjeet(at)singh(dot)im> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, richard(dot)vesely(at)softea(dot)sk, pgsql-bugs(at)lists(dot)postgresql(dot)org |
Subject: | Re: BUG #18016: REINDEX TABLE failure |
Date: | 2023-07-09 07:55:39 |
Message-ID: | ZKpn+44jciv6Ym3/@paquier.xyz |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs pgsql-hackers |
On Sun, Jul 09, 2023 at 12:01:03AM -0700, Gurjeet Singh wrote:
> Preliminary reading of the code indicates that a simple rearrangement
> of the code in reindex_relation() would be sufficient to get the
> desired behaviour. The code towards the bottom in that function,
> protected by `if ((flags & REINDEX_REL_PROCESS_TOAST ...)` needs to be
> moved to just before the `foreach(indexId, indexIds)` loop.
I guess that it should be OK to do that from the point where
reltoastrelid is known, when extracted the parent relation locked with
this ShareLock.
> The only downside I see so far with the proposed change is that the
> toast tables are currently reindexed after table_close() call, but
> after the proposed change they'll be reindexed before that call to
> close_table(). But since close_table() does not release the ShareLock
> on the table that is taken at the beginning of reindex_relation(), I
> don't think we'll losing anything by the proposed rearrangement of
> code.
That should be OK, I assume. However, if this is improved and
something we want to support in the long-run I guess that a TAP test
may be appropriate.
--
Michael
From | Date | Subject | |
---|---|---|---|
Next Message | Richard Veselý | 2023-07-09 13:54:35 | RE: BUG #18016: REINDEX TABLE failure |
Previous Message | Gurjeet Singh | 2023-07-09 07:01:03 | Re: BUG #18016: REINDEX TABLE failure |
From | Date | Subject | |
---|---|---|---|
Next Message | Pavel Luzanov | 2023-07-09 10:56:44 | Re: psql: Add role's membership options to the \du+ command |
Previous Message | Michael Paquier | 2023-07-09 07:36:11 | Re: Autogenerate some wait events code and documentation |