Обсуждение: REINDEX CONCURRENTLY and indisreplident

Hi all,

I have bumped into $subject, causing a replica identity index to
be considered as dropped if running REINDEX CONCURRENTLY on it.  This
means that the old tuple information would get lost in this case, as
a REPLICA IDENTITY USING INDEX without a dropped index is the same as
NOTHING.

Attached is a fix for this issue, that needs a backpatch down to 12.
Thanks,
--
Michael

On Wed, Jun 03, 2020 at 12:40:38PM -0300, Euler Taveira wrote:
> On Wed, 3 Jun 2020 at 03:54, Michael Paquier <michael@paquier.xyz> wrote:
>> I have bumped into $subject, causing a replica identity index to
>> be considered as dropped if running REINDEX CONCURRENTLY on it.  This
>> means that the old tuple information would get lost in this case, as
>> a REPLICA IDENTITY USING INDEX without a dropped index is the same as
>> NOTHING.
>
> LGTM. I tested in both versions (12, master) and it works accordingly.

Thanks for the review.  I'll try to get that fixed soon.

By the way, your previous email was showing up as part of my own email
with the indentation that was used so I missed it first.  That's the
case as well here:
https://www.postgresql.org/message-id/CAH503wDaejzhP7+wA-hHS6c7NzE69oWqe5Zf_TYFu1epAwp6EQ@mail.gmail.com
--
Michael

On Thu, Jun 04, 2020 at 11:23:36AM +0900, Michael Paquier wrote:
> On Wed, Jun 03, 2020 at 12:40:38PM -0300, Euler Taveira wrote:
> > On Wed, 3 Jun 2020 at 03:54, Michael Paquier <michael@paquier.xyz> wrote:
> >> I have bumped into $subject, causing a replica identity index to
> >> be considered as dropped if running REINDEX CONCURRENTLY on it.  This
> >> means that the old tuple information would get lost in this case, as
> >> a REPLICA IDENTITY USING INDEX without a dropped index is the same as
> >> NOTHING.
> >
> > LGTM. I tested in both versions (12, master) and it works accordingly.
>
> Thanks for the review.  I'll try to get that fixed soon.

Applied this one, just in time before the branching:
https://www.postgresql.org/message-id/1931934b-09dc-e93e-fab9-78c5bc72743d@postgresql.org
--
Michael