From: | Thomas Munro <thomas(dot)munro(at)enterprisedb(dot)com> |
---|---|
To: | David Rowley <david(dot)rowley(at)2ndquadrant(dot)com> |
Cc: | Bartosz Polnik <bartoszpolnik(at)gmail(dot)com>, PostgreSQL mailing lists <pgsql-bugs(at)lists(dot)postgresql(dot)org> |
Subject: | Re: BUG #15577: Query returns different results when executed multiple times |
Date: | 2019-01-09 20:20:42 |
Message-ID: | CAEepm=0ZqJp2nXRZf8e9ys6Utyu96QVy0=L8Q=-2UoDxwY=smA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
On Thu, Jan 10, 2019 at 5:35 AM David Rowley
<david(dot)rowley(at)2ndquadrant(dot)com> wrote:
> On Wed, 9 Jan 2019 at 17:01, Thomas Munro <thomas(dot)munro(at)enterprisedb(dot)com> wrote:
> > What exactly is being corrupted and how, I don't yet know, and I need
> > to leave this here for today, but that's what I've got so far.
>
> From what I can see it seems to be the parameter for the index scan
> that gets the wrong value.
>
> [explanation about redundant qual tba.source_id = tc.id and corrupted parameter]
Oh, yeah, that'd do it. Here are some excerpts from my printf
debugging, all from the leader process:
[51461] nestloop plan id 2 setting paramno 0 to value 100112
[51461] IndexScan returning a tuple (att1 = 1000010, att2 = 100112)
[51461] --- NestLoop got inner att2 = 100112 <--- FIRST TUPLE MADE IT OUT
[51461] nestloop plan id 0 setting paramno 0 to value 100112
[51461] gather will read tuple from queue
[51461] nestloop plan id 0 setting paramno 0 to value 98662 <--- OOPS
[51461] IndexScan returning a tuple (att1 = 1000009, att2 = 100112)
[51461] dropping a tuple (att1 = 1000009, att2 = 100112) <--- NEXT ONE DIDN'T
[51461] IndexScan returning a tuple (att1 = 1000008, att2 = 100112)
[51461] dropping a tuple (att1 = 1000008, att2 = 100112) <--- DITTO
...
So it's not the reading of the tuple queue per se, but the resulting
visit to a higher part of the plan when the Gather node emits a tuple.
It can't be right that plan id 2 and plan id 0 are both using paramno
0, can it? I'm not too familiar with the planner code that allocates
those but will go and poke at it.
--
Thomas Munro
http://www.enterprisedb.com
From | Date | Subject | |
---|---|---|---|
Next Message | Thomas Munro | 2019-01-09 20:31:57 | Re: BUG #15577: Query returns different results when executed multiple times |
Previous Message | David Rowley | 2019-01-09 16:34:53 | Re: BUG #15577: Query returns different results when executed multiple times |