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
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 |