pg.ddx.io  pgsql-bugs@postgresql.org mailing list archive  
help / color / mirror / Atom feed
From: Andres Freund <andres@anarazel.de>
To: Michael Paquier <michael@paquier.xyz>
Cc: Noah Misch <noah@leadboat.com>
Cc: Alexey Ermakov <alexey.ermakov@dataegret.com>
Cc: Robert Haas <robertmhaas@gmail.com>
Cc: Maxim Boguk <maxim.boguk@gmail.com>
Cc: PostgreSQL mailing lists <pgsql-bugs@lists.postgresql.org>
Cc: Peter Geoghegan <pg@bowt.ie>
Subject: Re: BUG #17268: Possible corruption in toast index after reindex index concurrently
Date: Mon, 8 Nov 2021 21:08:48 -0800
Message-ID: <20211109050848.oe3u6mhtomkaoxrx@alap3.anarazel.de> (raw)
In-Reply-To: <YYoA24hSkx6EYWpx@paquier.xyz>
References: <CAK-MWwTEWO2zzV-1ddm2mpurdv_3wAXwB3u_eh5W7xHM+SrsMQ@mail.gmail.com>
	<E6013BD3-5114-4338-AA03-7FBBE23FEC33@anarazel.de>
	<CAK-MWwQGv-wjcSrYeGE8fCW0=KYGE1tSMoH-fJ8maWV3kfe9iQ@mail.gmail.com>
	<366f7247-709e-c07c-4875-068be1121c3a@dataegret.com>
	<20211108183646.r3y6pldylxngxwl4@alap3.anarazel.de>
	<20211108185317.fz42txmnkqdkpix6@alap3.anarazel.de>
	<20211108203641.whpia3pzjofellf4@alap3.anarazel.de>
	<20211109035624.GA940092@rfd.leadboat.com>
	<B706E617-2172-4460-845A-B76E5DB2E0A2@anarazel.de>
	<YYoA24hSkx6EYWpx@paquier.xyz>

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@leadboat.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





view thread (28+ messages)  latest in thread

Message-ID: <20211109050848.oe3u6mhtomkaoxrx@alap3.anarazel.de>
Permalink:  ../20211109050848.oe3u6mhtomkaoxrx@alap3.anarazel.de/
Also on:    postgresql.org/message-id/20211109050848.oe3u6mhtomkaoxrx@alap3.anarazel.de

 · 

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: pgsql-bugs@postgresql.org
  Cc: andres@anarazel.de, michael@paquier.xyz, noah@leadboat.com, alexey.ermakov@dataegret.com, robertmhaas@gmail.com, maxim.boguk@gmail.com, pgsql-bugs@lists.postgresql.org, pg@bowt.ie
  Subject: Re: BUG #17268: Possible corruption in toast index after reindex index concurrently
  In-Reply-To: <20211109050848.oe3u6mhtomkaoxrx@alap3.anarazel.de>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox