PG17 compatibility - Check if there are blocks left in columnar_scan_analyze_next_block (#7738)

In PG17, the outer loop in `acquire_sample_rows()` changed
from
`while (BlockSampler_HasMore(&bs))`
to
`while (table_scan_analyze_next_block(scan, stream))`

Relevant PG commit:
041b96802efa33d2bc9456f2ad946976b92b5ae1

041b96802e

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
pull/7922/head
Naisila Puka 2024-11-18 17:27:49 +03:00 committed by naisila
parent c8d9a1bd10
commit 5540096b9a
1 changed files with 12 additions and 0 deletions

View File

@ -1437,7 +1437,19 @@ columnar_scan_analyze_next_block(TableScanDesc scan,
* to pages boundaries. So not much to do here. We return true anyway * to pages boundaries. So not much to do here. We return true anyway
* so acquire_sample_rows() in analyze.c would call our * so acquire_sample_rows() in analyze.c would call our
* columnar_scan_analyze_next_tuple() callback. * columnar_scan_analyze_next_tuple() callback.
* In PG17, we return false in case there is no buffer left, since
* the outer loop changed in acquire_sample_rows(), and it is
* expected for the scan_analyze_next_block function to check whether
* there are any blocks left in the block sampler.
*/ */
#if PG_VERSION_NUM >= PG_VERSION_17
Buffer buf = read_stream_next_buffer(stream, NULL);
if (!BufferIsValid(buf))
{
return false;
}
ReleaseBuffer(buf);
#endif
return true; return true;
} }