From 5540096b9a37c58ce09d10cbb41f1107dbe7ce56 Mon Sep 17 00:00:00 2001 From: Naisila Puka <37271756+naisila@users.noreply.github.com> Date: Mon, 18 Nov 2024 17:27:49 +0300 Subject: [PATCH] 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 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 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 --- src/backend/columnar/columnar_tableam.c | 12 ++++++++++++ 1 file changed, 12 insertions(+) diff --git a/src/backend/columnar/columnar_tableam.c b/src/backend/columnar/columnar_tableam.c index 8a1badd1d..92a4b2342 100644 --- a/src/backend/columnar/columnar_tableam.c +++ b/src/backend/columnar/columnar_tableam.c @@ -1437,7 +1437,19 @@ columnar_scan_analyze_next_block(TableScanDesc scan, * to pages boundaries. So not much to do here. We return true anyway * so acquire_sample_rows() in analyze.c would call our * 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; }