| From: | Peter Geoghegan <pg(at)bowt(dot)ie> |
|---|---|
| To: | Natalya Aksman <natalya(at)tigerdata(dot)com> |
| Cc: | Masahiro Ikeda <ikedamsh(at)oss(dot)nttdata(dot)com>, Tomas Vondra <tomas(at)vondra(dot)me>, Masahiro(dot)Ikeda(at)nttdata(dot)com, pgsql-hackers(at)lists(dot)postgresql(dot)org, Masao(dot)Fujii(at)nttdata(dot)com |
| Subject: | Re: Adding skip scan (including MDAM style range skip scan) to nbtree |
| Date: | 2025-09-10 16:54:36 |
| Message-ID: | CAH2-WznsZdjaSQL_CT2TpYoLmOE-k8-rHB27mJcdAg0+UnU+7A@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Wed, Sep 10, 2025 at 12:45 PM Peter Geoghegan <pg(at)bowt(dot)ie> wrote:
> I don't understand why it is that our not resetting the so->Skipscan
> flag within btrescan has any particular significance to Timescaledb,
> relative to all of the other fields that are supposed to be set by
> _bt_preprocess_keys.
I notice that the skipScan flag isn't initialized in the path where
there's no array keys at all on this rescan.
Does the attached patch (which moves back the initialization such that
the flag will always be initialized on rescan) fix the problem you're
seeing?
> What is the actual failure you see? Is it an
> assertion failure within _bt_readpage/_bt_checkkeys?
Still curious about this.
--
Peter Geoghegan
| Attachment | Content-Type | Size |
|---|---|---|
| 0001-Initialize-skipScan-field-consistently.patch | application/octet-stream | 1.3 KB |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Jeff Davis | 2025-09-10 16:58:08 | Re: Incorrect logic in XLogNeedsFlush() |
| Previous Message | Peter Geoghegan | 2025-09-10 16:45:38 | Re: Adding skip scan (including MDAM style range skip scan) to nbtree |