Re: BUG #15577: Query returns different results when executedmultiple times
От | Thomas Munro |
---|---|
Тема | Re: BUG #15577: Query returns different results when executedmultiple times |
Дата | |
Msg-id | CAEepm=2KvDWQbQCHdUW5hznvpzFHUf=htj=RwBjCcHhkgBnPVA@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: BUG #15577: Query returns different results when executed multiple times (Andrew Gierth <andrew@tao11.riddles.org.uk>) |
Ответы |
Re: BUG #15577: Query returns different results when executed multiple times
|
Список | pgsql-bugs |
On Thu, Jan 10, 2019 at 10:04 AM Andrew Gierth <andrew@tao11.riddles.org.uk> wrote: > So I think you're right to finger the planner's allocation of params as > the culprit. Looking at replace_nestloop_params_mutator, it's keeping a > list of nestloop params in root->curOuterParams (thus, globally to the > whole subquery being planned), and it assumes that if equal() is true > between the value of an existing nestloop param (which must be a Var) > and the Var for the one it's trying to create, then it's ok to use the > existing one. > > But clearly this can't work if one param is referenced both inside and > outside a Gather, because while they will compare equal for Vars, they > won't actually have the same value thanks to rows coming in from > workers. But if they used different params, there could be different problems, no? It's logically the same var. This makes me wonder if we need some kind of scheme for saving and restoring affected params whenever Gather switches between executing the plan directly and emitting tuples from workers, or something like that... -- Thomas Munro http://www.enterprisedb.com
В списке pgsql-bugs по дате отправления: