Bug: Re-executing the same parameterized write query can crash with `SIGSEGV`

[ericyuanhui]

Ladybug version

v0.20.0

What operating system are you using?

ubuntu24

What happened?

Problem

Re-executing the same parameterized write query can crash with SIGSEGV when the query performs a relationship MERGE followed by a separate relationship property SET.

Example:

UNWIND $rows AS row
MATCH (e:eventaccess {id: row.eventaccess_id})
MATCH (a:authentication {id: row.authentication_id})
MERGE (e)-[r:access_test_property]->(a)
SET r.update_time = TIMESTAMP(row.update_time),
    r.tag_code = row.tag_code;

The first execution succeeds, but the second execution of the same query string with different parameter values crashes in:

lbug::storage::RelTable::update()
lbug::processor::SingleLabelRelSetExecutor::set()
lbug::processor::SetRelProperty::getNextTuplesInternal()

core dump 
Core: python3 reproduce_cached_rel_merge_set.py
Signal: SIGSEGV

#0  lbug::storage::RelTable::update()
    project/ladybug/src/storage/table/rel_table.cpp:252
    localTable->update(&DUMMY_TRANSACTION, updateState);

#1  lbug::processor::SingleLabelRelSetExecutor::set()
    project/ladybug/src/processor/operator/persistent/set_executor.cpp:114

#2  lbug::processor::SetRelProperty::getNextTuplesInternal()
    project/ladybug/src/processor/operator/persistent/set.cpp:35

#3  lbug::processor::PhysicalOperator::getNextTuple()
    project/ladybug/src/processor/operator/physical_operator.cpp:227

#4  lbug::processor::ResultCollector::executeInternal()
    project/ladybug/src/processor/operator/result_collector.cpp:47

#5  lbug::processor::Sink::execute()

#6  lbug::processor::ProcessorTask::run()

#7  lbug::common::TaskScheduler::runWorkerThread()

reproduce script 

[reproduce_cached_rel_merge_set.py](https://github.com/user-attachments/files/31643567/reproduce_cached_rel_merge_set.py)

### Are there known steps to reproduce?

_No response_

[adsharma]

Fixed in 0.20.1

[ericyuanhui]

@adsharma I believe this issue has not been fixed. I built and tested using the latest main branch this afternoon and reproduced the problem. You can try my‑to‑reproduce script attached with the latest main branch.

[adsharma]

Ack. Getting handled in #877 and #878

[ericyuanhui]

fix on #876

[adsharma]

@ericyuanhui

CALL enable_cached_prepared_statement='reads'

on main should have the same effect as #876