Re: 2022-06-16 release announcement draft

From: Peter Geoghegan <pg(at)bowt(dot)ie>
To: "Jonathan S(dot) Katz" <jkatz(at)postgresql(dot)org>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: 2022-06-16 release announcement draft
Date: 2022-06-14 01:34:56
Message-ID: CAH2-Wz=jk9FJDbGHwYSs0BnS0b9irxsoVU5z7obc=fZNBLM3cA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Mon, Jun 13, 2022 at 6:15 PM Jonathan S. Katz <jkatz(at)postgresql(dot)org> wrote:
> > Perhaps it is also worth mentioning that you can use REINDEX without
> > CONCURRENTLY, even before upgrading.
>
> I'm hesitant on giving too many options. We did put out the "warning"
> announcement providing this as an option. I do think that folks who are
> running CIC/RIC are sensitive to locking, and a plain old "REINDEX" may
> be viable except in an emergency.

The locking implications for plain REINDEX are surprising IMV -- and
so I suggest sticking with what you have here.

In many cases using plain REINDEX is not meaningfully different to
taking a full AccessExclusiveLock on the table (we only acquire an AEL
on the index, but in practice that can be a distinction without a
difference). We at least went some way towards making the situation
with REINDEX locking clearer in a doc patch that recently became
commit 8ac700ac.

--
Peter Geoghegan

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Geoghegan 2022-06-14 01:41:17 Re: Tightening behaviour for non-immutable behaviour in immutable functions
Previous Message Jonathan S. Katz 2022-06-14 01:15:14 Re: 2022-06-16 release announcement draft