Re: repack: fix a bug to reject deferrable primary key fallback for concurrent mode - Mailing list pgsql-hackers

From Antonin Houska
Subject Re: repack: fix a bug to reject deferrable primary key fallback for concurrent mode
Date
Msg-id 65564.1776696735@localhost
Whole thread
In response to repack: fix a bug to reject deferrable primary key fallback for concurrent mode  (Chao Li <li.evan.chao@gmail.com>)
List pgsql-hackers
Chao Li <li.evan.chao@gmail.com> wrote:

> I am continuing to test REPACK, and I found another issue.
> 
> In check_concurrent_repack_requirements(), if a table has no replica identity index, the code falls back to using the
primarykey if one exists. The problem is that a deferrable primary key cannot be used for this purpose. WAL generation
doesnot consider a deferrable primary key to be a replica identity, so concurrent mode may not receive enough old tuple
informationto replay concurrent changes.
 

Thanks for finding it, this is certainly a problem.

I'm just thinking if it's worth a separate error message.
RelationGetIndexList() just ignores the deferrable PK

    if (replident == REPLICA_IDENTITY_DEFAULT && OidIsValid(pkeyIndex) && !pkdeferrable)
        relation->rd_replidindex = pkeyIndex;

and if there's no other suitable index, the result is that there is no
identity index for the table. So the change attached here should be consistent
with this approach.

-- 
Antonin Houska
Web: https://www.cybertec-postgresql.com


Attachment

pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Adding REPACK [concurrently]
Next
From: "Greg Burd"
Date:
Subject: Re: Add bms_offset_members() function for bitshifting Bitmapsets