On Tue, Sep 08, 2020 at 06:25:03PM +0000, Jameson, Hunter 'James' wrote:
> Hi, I ran across a small (but annoying) bug in initializing parallel BTree scans, which causes the parallel-scan
statemachine to get confused. The fix is one line; the description is a bit longer—
What postgres version was this ?
> Before, function _bt_first() would exit immediately if the specified scan keys could never be satisfied--without
notifyingother parallel workers, if any, that the scan key was done. This moved that particular worker to a scan key
beyondwhat was in the shared parallel-query state, so that it would later try to read in "InvalidBlockNumber", without
recognizingit as a special sentinel value.
>
> The basic bug is that the BTree parallel query state machine assumes that a worker process is working on a key <= the
globalkey--a worker process can be behind (i.e., hasn't finished its work on a previous key), but never ahead. By
allowingthe first worker to move on to the next scan key, in this one case, without notifying other workers, the global
keyends up < the first worker's local key.
>
> Symptoms of the bug are: on R/O, we get an error saying we can't extend the index relation, while on an R/W we just
extendthe index relation by 1 block.
What's the exact error ? Are you able to provide a backtrace ?
> To reproduce, you need a query that:
>
> 1. Executes parallel BTree index scan;
> 2. Has an IN-list of size > 1;
Do you mean you have an index on col1 and a query condition like: col1 IN (a,b,c...) ?
> 3. Has an additional index filter that makes it impossible to satisfy the
> first IN-list condition.
.. AND col1::text||'foo' = '';
I think you mean that the "impossible" condition makes it so that a btree
worker exits early.
> (We encountered such a query, and therefore the bug, on a production instance.)
Could you send the "shape" of the query or its plan, obfuscated and redacted as
need be ?
--
Justin