| 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
| 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 |