On Wed, 23 Sept 2026 at 23:41, Sami Imseih <[email protected]> wrote: > > > v2 fixes the issue you mentioned. > > Thanks for checking! > > > I think It also fixes another case. If the added column is in the replica > > identity index, REPACK looks up the row with a NULL key. That fails the > > Assert in find_target_tuple(), or gives "could not find target tuple" > > without assertions. Adding this to the test covers it: > > > > CREATE UNIQUE INDEX repack_test_i_c_idx ON repack_test (i, c); > > ALTER TABLE repack_test REPLICA IDENTITY USING INDEX > > repack_test_i_c_idx; > > ahh, good repro. It's worse for a pass-by-reference column, i.e. TEXT. > find_target_tuple() only sets sk_argument, never SK_ISNULL, so the > comparison function gets a NULL pointer rather than a NULL key. > So a non assert build will actually segfault. > > v3 uses a TEXT column in the identity index, which covers the int case > too since both go through the same sk_argument. > > -- > Sami Imseih > Amazon Web Services (AWS)
Hi! I reproduced this while stress testing REPACK (CONCURRENTLY) on HEAD. Whats worse, this issue makes the database unrestorable via pg_dump/COPY. I also checked DROP COLUMN, ALTER TYPE, SET STORAGE, SET COMPRESSION, SET NOT NULL, ADD/DROP CONSTRAINT NOT VALID/VALIDATE, virtual generated columns and found no related issue (both with and without v3). So patch LGTM -- Best regards, Kirill Reshke
