> Hmm, so how would that transaction look like? My reading of the WAL
> (based on the available relfilenode info) is this:
>
> Transaction 25EE/D66F0438 ASSIGNMENT xtop 1667601527: subxacts: 1667601528
>
> -> seems like a savepoint, probably
>
> Heap 25EE/D66F11E8 INSERT off 4, blkref #0: rel 1663/13018/88964795 blk 3125
> Heap 25EE/D66F2118 INSERT off 7, blkref #0: rel 1663/13018/88964795 blk 3139 FPW
> Btree 25EE/D66F54C8 INSERT_LEAF off 257, blkref #0: rel 1663/13018/88964797 blk 15840
> Heap 25EE/D66F5508 INSERT off 2, blkref #0: rel 1663/13018/88964792 blk 18475
> Btree 25EE/D66F6738 INSERT_LEAF off 140, blkref #0: rel 1663/13018/88964798 blk 2058
> Btree 25EE/D66F7E40 INSERT_LEAF off 28, blkref #0: rel 1663/13018/88964799 blk 5076
> Btree 25EE/D66F7EA0 INSERT_LEAF off 88, blkref #0: rel 1663/13018/88964800 blk 3412
>
> -> insert into TOAST table (88964795) + TOAST idx (probably 88964797)
> -> then an insert into table2 (88964792), and it's indexes
I think it's an insert into table2 (which has at least four indexes),
followed by insertion in 3 indexes, followed by failure to insert into
the fourth index (which naturally does not appear in WAL).
> Heap 25EE/D66F7EF0 DELETE off 2 , blkref #0: rel 1663/13018/88964792 blk 18475
Then the heap insertion is speculative-aborted because of failure to
insert into the fourth index ...
> Heap 25EE/D66F7F28 DELETE off 4 , blkref #0: rel 1663/13018/88964795 blk 3125
> Heap 25EE/D66F7F60 DELETE off 7 , blkref #0: rel 1663/13018/88964795 blk 3139
... and this propagates to the toast table (toast_delete in
heap_abort_speculative)
I didn't look from this point down. I'll look at your reproducer script
now; I think you need to make it so that the index specified in the ON
CONFLICT clause is the fourth one in OID order. (Not really sure how
relevant the other index insertions are, really.)
--
Álvaro Herrera https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services