| From: | Andres Freund <andres(at)anarazel(dot)de> |
|---|---|
| To: | Michael Paquier <michael(at)paquier(dot)xyz> |
| Cc: | Noah Misch <noah(at)leadboat(dot)com>, Alexey Ermakov <alexey(dot)ermakov(at)dataegret(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, Maxim Boguk <maxim(dot)boguk(at)gmail(dot)com>, PostgreSQL mailing lists <pgsql-bugs(at)lists(dot)postgresql(dot)org>, Peter Geoghegan <pg(at)bowt(dot)ie> |
| Subject: | Re: BUG #17268: Possible corruption in toast index after reindex index concurrently |
| Date: | 2021-11-09 05:08:48 |
| Message-ID: | 20211109050848.oe3u6mhtomkaoxrx@alap3.anarazel.de |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-bugs |
Hi,
On 2021-11-09 14:02:19 +0900, Michael Paquier wrote:
> On Mon, Nov 08, 2021 at 08:37:58PM -0800, Andres Freund wrote:
> > On November 8, 2021 7:56:24 PM PST, Noah Misch <noah(at)leadboat(dot)com> wrote:
> >> On Mon, Nov 08, 2021 at 12:36:41PM -0800, Andres Freund wrote:
> >>> One possible way to fix this would be to make ReindexRelationConcurrently()
> >>> acquire a lock on the underlying table when reindexing a toast table. Another
> >>> to not release the lock in toast_save_datum().
>
> Thanks for the test case. That reproduces really quickly.
>
> >> The latter is more future-proof. Does it have material disadvantages?
> >
> > I don't immediately see any. But I've been long of the opinion, and
> > had plenty discussions around it, that our habit of releasing locks
> > early is far too widely used.
>
> Yes, I'd agree that not patching the reindex concurrent path would be
> safer in the long run. This feels a bit like e629a01, in spirit, not
> in scope.
I wonder if we should do both...
Greetings,
Andres Freund
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Noah Misch | 2021-11-09 05:46:25 | Re: BUG #17268: Possible corruption in toast index after reindex index concurrently |
| Previous Message | Michael Paquier | 2021-11-09 05:02:19 | Re: BUG #17268: Possible corruption in toast index after reindex index concurrently |