Re: bug: ANALYZE progress report with inheritance tables - Mailing list pgsql-hackers

From Heikki Linnakangas
Subject Re: bug: ANALYZE progress report with inheritance tables
Date
Msg-id 477b3908-98cb-386b-a8bc-274e7203d388@iki.fi
Whole thread Raw
In response to Re: bug: ANALYZE progress report with inheritance tables  (Heikki Linnakangas <hlinnaka@iki.fi>)
List pgsql-hackers
On 28/09/2023 19:06, Heikki Linnakangas wrote:
> On 22/01/2023 18:23, Justin Pryzby wrote:
>> pg_stat_progress_analyze was added in v13 (a166d408e).
>>
>> For tables with inheritance children, do_analyze_rel() and
>> acquire_sample_rows() are called twice.  The first time through,
>> pgstat_progress_start_command() has memset() the progress array to zero.
>>
>> But the 2nd time, ANALYZE_BLOCKS_DONE is already set from the previous
>> call, and BLOCKS_TOTAL can be set to some lower value (and in any case a
>> value unrelated to the pre-existing value of BLOCKS_DONE).  So the
>> progress report briefly shows a bogus combination of values and, with
>> these assertions, fails regression tests in master and v13, unless
>> BLOCKS_DONE is first zeroed.
> 
> Good catch!
> 
> I think the counts need do be reset even earlier, in
> acquire_inherited_sample_rows(), at the same time that we update
> PROGRESS_ANALYZE_CURRENT_CHILD_TABLE_RELID. See attached patch.
> Otherwise, there's a brief moment where we have already updated the
> child table ID, but the PROGRESS_ANALYZE_BLOCKS_TOTAL
> PROGRESS_ANALYZE_BLOCKS_DONE still show the counts from the previous
> child table. And if it's a foreign table, the FDW's sampling function
> might not update the progress report at all, in which case the old
> values will be displayed until the table is fully processed.

Committed and backported. Thank you!

-- 
Heikki Linnakangas
Neon (https://neon.tech)




pgsql-hackers by date:

Previous
From: Joe Conway
Date:
Subject: Re: commitfest app down for repairs
Next
From: vignesh C
Date:
Subject: Remove ParallelReadyList and worker_spi_state from typedefs.list