Re: [UNVERIFIED SENDER] Re: Fix for parallel BTree initialization bug - Mailing list pgsql-hackers

From Jameson, Hunter 'James'
Subject Re: [UNVERIFIED SENDER] Re: Fix for parallel BTree initialization bug
Date
Msg-id 551F05FF-2363-4D58-9BC7-46A56918DE06@amazon.com
Whole thread Raw
List pgsql-hackers
Also, the behavior (=line of code) added by the bug fix is the same as existing code in the same function, _bt_first(),
atlines 898, 1096, 1132, 1367. And the calls to _bt_parallel_readpage(), line 903, and _bt_steppage(), line 1416, will
alsoultimately call _bt_parallel_done(). So the bug seems to be a pretty simple oversight: in 6 out of 7 cases in
_bt_first(),we call _bt_parallel_done() before returning "false"; but in the 7th case (fixed in this bug fix), we do
not.The fix is to make case #7 the same as the other 6.
 

James

On 9/9/20, 7:11 AM, "Jameson, Hunter 'James'" <hunjmes@amazon.com> wrote:

    Hi, I spent some time trying to create a repro (other than testing it on the production instance where we
encounteredthe bug), but was unable to create one within a reasonable time.
 

    The tricky part is that the bug symptoms are run-time symptoms -- so not only do you need, first, to satisfy
conditions(1), (2), and (3), without the query optimizer optimizing them away! -- but you also need, second, a query
thatruns long enough for one or more of the parallel workers' state machines to get confused. (This wasn't a problem on
theproduction instance where we encountered the bug and I tested the fix.)
 

    Also, third-- passing InvalidBlockNumber to ReadBuffer() generally just appends a new block to the relation, so the
bugdoesn't even result in an error condition on an RW instance. (The production instance was RO...) So the bug,
althoughvery small!, is annoying!
 

    James

    On 9/9/20, 6:14 AM, "Amit Kapila" <amit.kapila16@gmail.com> wrote:

        CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless
youcan confirm the sender and know the content is safe.
 



        On Tue, Sep 8, 2020 at 11:55 PM Jameson, Hunter 'James'
        <hunjmes@amazon.com> wrote:
        >
        > Hi, I ran across a small (but annoying) bug in initializing parallel BTree scans, which causes the
parallel-scanstate machine to get confused.
 
        >
        >
        > To reproduce, you need a query that:
        >
        >
        >
        > 1. Executes parallel BTree index scan;
        >
        > 2. Has an IN-list of size > 1;
        >
        > 3. Has an additional index filter that makes it impossible to satisfy the
        >
        >     first IN-list condition.
        >
        >
        >
        > (We encountered such a query, and therefore the bug, on a production instance.)
        >
        >

        I think I can understand what you are pointing out here but it would
        be great if you can have a reproducible test case because that will
        make it apparent and we might want to include that in the regression
        tests if possible.

        --
        With Regards,
        Amit Kapila.



pgsql-hackers by date:

Previous
From: David Rowley
Date:
Subject: Re: Optimising compactify_tuples()
Next
From: Justin Pryzby
Date:
Subject: Re: doc review for v13