On Thu, Jan 10, 2019 at 5:35 AM David Rowley
<david.rowley@2ndquadrant.com> wrote:
> On Wed, 9 Jan 2019 at 17:01, Thomas Munro <thomas.munro@enterprisedb.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
