Re: Support tid range scan in parallel?

From: David Rowley <dgrowleyml(at)gmail(dot)com>
To: Pgsql Hackers <pgsql-hackers(at)postgresql(dot)org>
Cc: Cary Huang <cary(dot)huang(at)highgo(dot)ca>, Junwang Zhao <zhjwpku(at)gmail(dot)com>, Rafia Sabih <rafia(dot)pghackers(at)gmail(dot)com>
Subject: Re: Support tid range scan in parallel?
Date: 2025-11-27 13:31:05
Message-ID: CAApHDvo1swSL5R1-Z-eL70yErB6aujYNLZ4kud8XgHyh-cVW3w@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, 27 Nov 2025 at 18:48, David Rowley <dgrowleyml(at)gmail(dot)com> wrote:
> This seems to have caused issues on skink [1] under Valgrind. The
> problem seems to be that initscan() does not always initialise
> rs_startblock. I'm now trying to figure out if there's some reason for
> that, or if that's been overlooked at some point.

I've written the attached patch to address the uninitialised
rs_startblock field.

The patch basically adds:

if (!keep_startblock)
scan->rs_startblock = InvalidBlockNumber;

to initscan() when in parallel mode. The rest of the patch is a small
refactor to make it clearer which parts are for parallel and which are
for serial. I also added a comment to mention that the syncscan start
location is figured out in table_block_parallelscan_startblock_init()
for parallel scans.

David

> [1] https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=skink&dt=2025-11-27%2002%3A17%3A35

Attachment Content-Type Size
v1-0001-Fix-possibly-uninitialized-HeapScanDesc.rs_startb.patch application/octet-stream 4.4 KB

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Bertrand Drouvot 2025-11-27 14:17:23 Re: Remove unused function parameters, part 1: contrib
Previous Message Nazir Bilal Yavuz 2025-11-27 13:13:56 Re: https://cfbot.cputube.org - certificate has expired