Commit 39a2cc8
Fix TTS_EMPTY assertion when re-using scan slot after process_path
The four ExecStoreVirtualTuple calls in exec_cypher_merge were triggering
an Assert failure under --enable-cassert:
TRAP: failed Assert("TTS_EMPTY(slot)"), File: execTuples.c, Line: 1748
ExecStoreVirtualTuple (execTuples.c:1748) asserts that its target slot
is in the TTS_EMPTY state. In our MERGE executor, process_path writes
directly into the subquery's scan tuple slot -- which already holds the
subquery's output tuple and therefore is NOT empty. On a release build
the assertion compiles out and ExecStoreVirtualTuple just clears the flag
and sets tts_nvalid; on an --enable-cassert build the backend aborts and
takes down the regression run.
We only need the bookkeeping half of ExecStoreVirtualTuple (clear
TTS_FLAG_EMPTY and set tts_nvalid = natts) -- not the "store semantics"
that motivate the assertion. Add a small static helper
mark_scan_slot_valid() that does exactly the bookkeeping, and replace
the four call sites. Release-build behavior is byte-identical since
Assert() compiles to nothing; cassert-build behavior now matches release.
Caught by the cassert-enabled regression suite we reinstated after #2380.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>1 parent 5e968fb commit 39a2cc8
1 file changed
Lines changed: 22 additions & 4 deletions
| Original file line number | Diff line number | Diff line change | |
|---|---|---|---|
| |||
80 | 80 | | |
81 | 81 | | |
82 | 82 | | |
| 83 | + | |
83 | 84 | | |
84 | 85 | | |
85 | 86 | | |
| |||
357 | 358 | | |
358 | 359 | | |
359 | 360 | | |
360 | | - | |
| 361 | + | |
361 | 362 | | |
362 | 363 | | |
363 | 364 | | |
| |||
376 | 377 | | |
377 | 378 | | |
378 | 379 | | |
| 380 | + | |
| 381 | + | |
| 382 | + | |
| 383 | + | |
| 384 | + | |
| 385 | + | |
| 386 | + | |
| 387 | + | |
| 388 | + | |
| 389 | + | |
| 390 | + | |
| 391 | + | |
| 392 | + | |
| 393 | + | |
| 394 | + | |
| 395 | + | |
| 396 | + | |
379 | 397 | | |
380 | 398 | | |
381 | 399 | | |
| |||
723 | 741 | | |
724 | 742 | | |
725 | 743 | | |
726 | | - | |
| 744 | + | |
727 | 745 | | |
728 | 746 | | |
729 | 747 | | |
| |||
823 | 841 | | |
824 | 842 | | |
825 | 843 | | |
826 | | - | |
| 844 | + | |
827 | 845 | | |
828 | 846 | | |
829 | 847 | | |
| |||
987 | 1005 | | |
988 | 1006 | | |
989 | 1007 | | |
990 | | - | |
| 1008 | + | |
991 | 1009 | | |
992 | 1010 | | |
993 | 1011 | | |
| |||
0 commit comments