On Tue, Sep 15, 2020 at 8:54 AM Tom Lane wrote:
>
> Amit Kapila writes:
> > On Mon, Sep 14, 2020 at 11:26 PM Peter Geoghegan wrote:
> >> The fix seems sensible to me.
>
> > Thanks, I think it is better to wait for a day or two as yesterday
> > only we stamped 13 and we need to backpatch this.
>
Amit Kapila writes:
> On Mon, Sep 14, 2020 at 11:26 PM Peter Geoghegan wrote:
>> The fix seems sensible to me.
> Thanks, I think it is better to wait for a day or two as yesterday
> only we stamped 13 and we need to backpatch this.
Right, please avoid pushing anything non-critical to REL_13_STA
On Mon, Sep 14, 2020 at 11:26 PM Peter Geoghegan wrote:
>
> On Mon, Sep 14, 2020 at 5:37 AM Amit Kapila wrote:
> > I am planning to push this tomorrow after doing testing on
> > back-branches. Let me know if you have any comments.
>
> The fix seems sensible to me.
>
Thanks, I think it is better
On Mon, Sep 14, 2020 at 5:37 AM Amit Kapila wrote:
> I am planning to push this tomorrow after doing testing on
> back-branches. Let me know if you have any comments.
The fix seems sensible to me.
--
Peter Geoghegan
On Fri, Sep 11, 2020 at 4:41 PM Amit Kapila wrote:
>
> On Fri, Sep 11, 2020 at 8:07 AM Justin Pryzby wrote:
> >
> I have tested this on HEAD. It would be great if you can verify in
> back branches as well. I'll also do it before commit.
>
I am planning to push this tomorrow after doing testing o
On Fri, Sep 11, 2020 at 8:07 AM Justin Pryzby wrote:
>
> Against all odds, I was able to reproduce this.
>
Thanks, this helps me to understand the problem. So whats going on
here is that once one of the workers has moved to the next set of scan
keys without incrementing parallel shared key count
Nice repro, thanks!
--
James Hunter, Amazon Web Services (AWS)
On 9/10/20 7:37 PM, Justin Pryzby wrote:
Against all odds, I was able to reproduce this.
begin;
CREATE TABLE t AS SELECT generate_series(1,99)i;
ALTER TABLE t SET (parallel_workers=2, autovacuum_enabled=off);
CREATE INDEX ON t(i
Against all odds, I was able to reproduce this.
begin;
CREATE TABLE t AS SELECT generate_series(1,99)i;
ALTER TABLE t SET (parallel_workers=2, autovacuum_enabled=off);
CREATE INDEX ON t(i);
commit;
SET parallel_leader_participation=off; SET min_parallel_table_scan_size=0; SET
enable_bitmapsc
Answers inline below:
On 9/10/20, 4:58 AM, "Amit Kapila" wrote:
CAUTION: This email originated from outside of the organization. Do not
click links or open attachments unless you can confirm the sender and know the
content is safe.
On Tue, Sep 8, 2020 at 11:55 PM Jameson, Hunter 'J
Answers inline below, sorry for the formatting-- am still trying to get
corporate email to work nicely with this mailing list, thanks.
On 9/9/20, 9:22 PM, "Justin Pryzby" wrote:
CAUTION: This email originated from outside of the organization. Do not
click links or open attachments unless
On Tue, Sep 8, 2020 at 11:55 PM Jameson, Hunter 'James'
wrote:
>
> Hi, I ran across a small (but annoying) bug in initializing parallel BTree
> scans, which causes the parallel-scan state machine to get confused. The fix
> is one line; the description is a bit longer—
>
>
>
> Before, function _b
On Tue, Sep 08, 2020 at 06:25:03PM +, Jameson, Hunter 'James' wrote:
> Hi, I ran across a small (but annoying) bug in initializing parallel BTree
> scans, which causes the parallel-scan state machine to get confused. The fix
> is one line; the description is a bit longer—
What postgres versi
Also, the behavior (=line of code) added by the bug fix is the same as existing
code in the same function, _bt_first(), at lines 898, 1096, 1132, 1367. And the
calls to _bt_parallel_readpage(), line 903, and _bt_steppage(), line 1416, will
also ultimately call _bt_parallel_done(). So the bug see
Hi, I spent some time trying to create a repro (other than testing it on the
production instance where we encountered the 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 con
On Tue, Sep 8, 2020 at 11:55 PM Jameson, Hunter 'James'
wrote:
>
> Hi, I ran across a small (but annoying) bug in initializing parallel BTree
> scans, which causes the parallel-scan state machine to get confused.
>
>
> To reproduce, you need a query that:
>
>
>
> 1. Executes parallel BTree index
15 matches
Mail list logo
