Re: Assert("vacrel->eager_scan_remaining_successes > 0")

From: Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com>
To: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Cc: Melanie Plageman <melanieplageman(at)gmail(dot)com>
Subject: Re: Assert("vacrel->eager_scan_remaining_successes > 0")
Date: 2025-05-20 21:23:11
Message-ID: CAD21AoBCfbDCwyEpQHRqQ5X1dqe=vmjkkag-Gef1eNYFpjfbLg@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

(CC'ed to Melanie)

On Fri, May 2, 2025 at 11:59 AM Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com> wrote:
>
> Hi,
>
> I hit the assertion failure in the subject line with the following script:
>
> create table t (a int) with (autovacuum_enabled = off);
> insert into t select generate_series(1, 1_000_000);
> vacuum t;
> insert into t select generate_series(1, 1_000_000);
> set vacuum_freeze_min_age to 0;
> vacuum t;
>
> When the success count reaches to 0, we disable the eager scan by
> resetting related fields as follows:
>
> /*
> * If we hit our success cap, permanently disable eager
> * scanning by setting the other eager scan management
> * fields to their disabled values.
> */
> vacrel->eager_scan_remaining_fails = 0;
> vacrel->next_eager_scan_region_start = InvalidBlockNumber;
> vacrel->eager_scan_max_fails_per_region = 0;
>
> However, there is a possibility that we have already eagerly scanned
> another page and returned it to the read stream before we freeze the
> eagerly-scanned page and disable the eager scan. In this case, the
> next block that we retrieved from the read stream could also be an
> eagerly-scanned page.

I've added it to Open Items for v18.

If I understand correctly, there's a potential scenario where we might
eagerly scan more pages than permitted by the success and failure
caps. One question is: what is the practical magnitude of this excess
scanning? If the overflow could be substantial (for instance, eagerly
scanning 30% of table pages), we should consider revising our eager
scanning mechanism.

One potential solution would be to implement a counter tracking the
number of eagerly scanned but unprocessed pages. This counter could
then inform the decision-making process in
find_next_unskippable_block() regarding whether to proceed with eager
scanning of additional pages.

Alternatively, if the excess scanning proves negligible in practice,
we could adopt a simpler solution by allowing
vacrel->eager_scan_remaining_successes to accept negative values and
removing the assertion in question.

Regards,

--
Masahiko Sawada
Amazon Web Services: https://aws.amazon.com

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Jose Luis Tallon 2025-05-20 21:24:18 Re: Violation of principle that plan trees are read-only
Previous Message Jeff Davis 2025-05-20 21:12:41 Re: Avoid orphaned objects dependencies, take 3