On Sun, 23 Aug 2026 at 01:26, Mihail Nikalayeu <[email protected]> wrote: > > Hello, > > When the remote relation has REPLICA IDENTITY FULL and the local one > has no primary key or replica identity, the apply worker looks for any > index it can search by. > FindUsableIndexForReplicaIdentityFull() walks RelationGetIndexList() > and takes the first index of a suitable shape without checking if it > is valid. > That list omits only indexes that are not indislive, so the leftover > from a failed CREATE INDEX CONCURRENTLY is eligible -- and such an > index need not contain every row. > > A failed CIC validation leaves an index that scans cleanly but lacks > exactly the rows validation would have added. Consequently, updates > and deletes for those rows are dropped as update_missing conflicts and > the subscriber quietly diverges. > > A failed build leaves an index that is empty down to the metapage, > which parks the subscription in a permanent error: > ERROR: could not read blocks 0..0 in file "base/5/16433": read only 0 > of 8192 bytes > > The fix and a reproducer are in the attachments. > > Affects 16 and up, from 89e46da5e51.
Thanks for the patch, the patch does not apply on PG17 version, you might have to provide a separate patch for PG17 & below version: patch -p1 < v1-0001-Don-t-choose-an-invalid-index-for-REPLICA-IDENTIT.patch patching file 'src/backend/replication/logical/relation.c' 1 out of 1 hunks failed--saving rejects to 'src/backend/replication/logical/relation.c.rej' patching file 'src/test/subscription/t/032_subscribe_use_index.pl' Regards, Vignesh
