Fantastic, the patch is working, it fixes our issue! Thank you, Natalya Aksman.
On Wed, Sep 10, 2025 at 3:12 PM Peter Geoghegan <[email protected]> wrote: > On Wed, Sep 10, 2025 at 2:59 PM Natalya Aksman <[email protected]> > wrote: > > But after btrescan resets "so->numberOfKeys = 0", so->skipScan is not > reset to "false" in _bt_preprocess_keys because of this code: > https://github.com/postgres/postgres/blob/9016fa7e3bcde8ae4c3d63c707143af147486a10/src/backend/access/nbtree/nbtpreprocesskeys.c#L1847 > > After we set "so->numberOfKeys = 0" we quit on line 1847 before we get > to the line 1874 where we do "so->skipScan = (numSkipArrayKeys > 0);" > https://github.com/postgres/postgres/blob/9016fa7e3bcde8ae4c3d63c707143af147486a10/src/backend/access/nbtree/nbtpreprocesskeys.c#L1874 > > It sounds like the patch that I posted fixes the problem, without you > having to set so->skipScan externally (which sounds like a big > kludge). Can you confirm that it actually does fix the problem that > you're seeing? > > TimescaleDB isn't following the letter of the law here. But I do still > see the argument for consistently setting so->skipScan during > preprocessing. That at least makes sense on general robustness > grounds. > > -- > Peter Geoghegan >
