Re: Bug in batch tuplesort memory CLUSTER case (9.6 only)
От | Peter Geoghegan |
---|---|
Тема | Re: Bug in batch tuplesort memory CLUSTER case (9.6 only) |
Дата | |
Msg-id | CAM3SWZTOm7tXi1iW94FgNxdo5G5r0sdDwTmjxuOaA2qM0NZaUg@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Bug in batch tuplesort memory CLUSTER case (9.6 only) (Robert Haas <robertmhaas@gmail.com>) |
Ответы |
Re: Bug in batch tuplesort memory CLUSTER case (9.6 only)
|
Список | pgsql-hackers |
On Fri, Jul 1, 2016 at 6:23 AM, Robert Haas <robertmhaas@gmail.com> wrote: > The proposed patch contains no test case and no description of how to > reproduce the problem. I am not very keen on the idea of trying to > puzzle that out from first principles. I thought that the bug was simple enough that it didn't require a testcase. Besides, as I've often complained about there are no tests of external sorting in the regression test suite whatsoever. I don't think you'd just accept it now if I tried to add some. I could give you steps to reproduce the bug, but they involve creating a large table using my gensort tool [1]. It isn't trivial. Are you interested? > Also, I would appreciate a > clearer explanation of why this only affects CLUSTER tuplesorts. As I said, it has the only type of caller tuple that happens to itself contain a pointer to palloc()'d memory. Clearly that needs to be updated if the tuple is moved, since it always points to an offset into the same tuple. I thought that that explanation was simple. [1] https://github.com/petergeoghegan/gensort -- Peter Geoghegan
В списке pgsql-hackers по дате отправления: