Re: Autoprewarm workers terminated due to a segmentation fault
Matheus Alcantara <matheusssilv97@gmail.com>
From: "Matheus Alcantara" <matheusssilv97@gmail.com>
To: "Tomas Vondra" <tomas@vondra.me>, "Glauber Batista"
<glauberrbatista@gmail.com>, <pgsql-bugs@lists.postgresql.org>
Date: 2026-06-09T22:25:55Z
Lists: pgsql-bugs
Attachments
- v2-0001-Fix-out-of-bounds-access-in-autoprewarm-worker.patch (text/plain) patch v2-0001
On Tue Jun 9, 2026 at 6:44 PM -03, Tomas Vondra wrote:
> So how does it get advanced past the prewarm_stop_idx? I've been unable
> to reproduce it locally, maybe it's platform-specific. The original
> report was from ARM, are you on ARM too, Matheus?
>
Yes, I'm also on ARM. I also set pg_prewarm.autoprewarm_interval=10s on
postgresql.conf, not sure if it make more easier to reproduce.
> But AFAIK the code may not account for read stream callback updating the
> pos to prewarm_stop_idx? The callback may end with (p->pos =
> apw_state->prewarm_stop_idx), and that seems to be past the end of the
> array.
>
Yes, this is my understanding.
> That'd mean the proposed check is generally the correct way to fix this.
> TBH it's not clear to me why this needs to set the *next* entry at the
> end of the loop. Well, it does that so that the loop condition can use
> 'blk', but that seems a bit fragile / confusing, and no one noticed the
> issue.
>
> Maybe this would be a better way to write the while loop?
>
> while (i < apw_state->prewarm_stop_idx)
> {
> blk = block_info[i];
>
> if (blk.tablespace != tablespace ||
> blk.filenumber != filenumber)
> break;
>
> ...
> }
>
>
Is attached patch what are you sugesting? If yes, I agree that looks
better, it's more safe and easier to understand.
--
Matheus Alcantara
EDB: https://www.enterprisedb.com
Commits
-
Fix out-of-bounds access in autoprewarm worker
- 3bf2cb22576e 18 (unreleased) landed
- dac36601fd77 19 (unreleased) landed
-
Refactor autoprewarm_database_main() in preparation for read stream
- 6acab8bdbcda 18.0 cited