It is expected that the scan_analyze_next_block function will
check if there are any blocks left. So we add that check in
columnar_scan_analyze_next_block
Without this fix, we will have an indefinite loop causing timeout. Specifically, in our test schedules,
multi schedule stuck at drop_column_partitioned_table test
multi-mx schedule stuck at start_stop_metadata_sync test
columnar schedule stuck at columnar_create test
Note to reviewer: First three commits are for PG17 testing purposes. Only the last commit will be merged.
In PG17, the outer loop in
acquire_sample_rows()
changed fromwhile (BlockSampler_HasMore(&bs))
towhile (table_scan_analyze_next_block(scan, stream))
Relevant PG commit: 041b96802efa33d2bc9456f2ad946976b92b5ae1 https://github.com/postgres/postgres/commit/041b96802efa33d2bc9456f2ad946976b92b5ae1
It is expected that the
scan_analyze_next_block
function will check if there are any blocks left. So we add that check incolumnar_scan_analyze_next_block
Without this fix, we will have an indefinite loop causing timeout. Specifically, in our test schedules,
multi schedule
stuck atdrop_column_partitioned_table
testmulti-mx
schedule stuck atstart_stop_metadata_sync
testcolumnar schedule
stuck atcolumnar_create
testNote to reviewer: First three commits are for PG17 testing purposes. Only the last commit will be merged.