fix bug due to block_number argument being overridden by the optimistic path

This commit is contained in:
i-norden 2023-03-08 12:42:02 -06:00
parent 67dc84205a
commit c9edf6c832
2 changed files with 4 additions and 4 deletions

View File

@ -41,8 +41,8 @@ BEGIN
ORDER BY storage_cids.block_number DESC LIMIT 1; ORDER BY storage_cids.block_number DESC LIMIT 1;
-- check if result is from canonical state -- check if result is from canonical state
SELECT header_id, canonical_header_hash(tmp_tt_stg2.block_number), tmp_tt_stg2.block_number SELECT header_id, canonical_header_hash(tmp_tt_stg2.block_number)
INTO v_header, v_canonical_header, v_block_no INTO v_header, v_canonical_header
FROM tmp_tt_stg2 LIMIT 1; FROM tmp_tt_stg2 LIMIT 1;
IF v_header IS NULL OR v_header != v_canonical_header THEN IF v_header IS NULL OR v_header != v_canonical_header THEN

View File

@ -241,8 +241,8 @@ BEGIN
AND storage_cids.block_number <= v_block_no AND storage_cids.block_number <= v_block_no
ORDER BY storage_cids.block_number DESC LIMIT 1; ORDER BY storage_cids.block_number DESC LIMIT 1;
-- check if result is from canonical state -- check if result is from canonical state
SELECT header_id, canonical_header_hash(tmp_tt_stg2.block_number), tmp_tt_stg2.block_number SELECT header_id, canonical_header_hash(tmp_tt_stg2.block_number)
INTO v_header, v_canonical_header, v_block_no INTO v_header, v_canonical_header
FROM tmp_tt_stg2 LIMIT 1; FROM tmp_tt_stg2 LIMIT 1;
IF v_header IS NULL OR v_header != v_canonical_header THEN IF v_header IS NULL OR v_header != v_canonical_header THEN
RAISE NOTICE 'get_storage_at_by_number: chosen header NULL OR % != canonical header % for block number %, trying again.', v_header, v_canonical_header, v_block_no; RAISE NOTICE 'get_storage_at_by_number: chosen header NULL OR % != canonical header % for block number %, trying again.', v_header, v_canonical_header, v_block_no;