On Fri, Jul 1, 2016 at 12:06 AM, Noah Misch <noah@leadboat.com> wrote:
> On Sun, Jun 26, 2016 at 09:14:05PM -0700, Peter Geoghegan wrote:
>> In general, moving tuplesort.c batch memory caller tuples around
>> happens when batch memory needs to be recycled, or freed outright with
>> pfree().
>>
>> I failed to take into account that CLUSTER tuplesorts need an extra
>> step when moving caller tuples to a new location (i.e. when moving
>> HeapTuple caller tuples using memmove()), because their particular
>> variety of caller tuple happens to itself contain a pointer to
>> palloc()'d memory. Attached patch fixes this use-after-free bug.
>
> [Action required within 72 hours. This is a generic notification.]
>
> The above-described topic is currently a PostgreSQL 9.6 open item. Robert,
> since you committed the patch believed to have created it, you own this open
> item. If some other commit is more relevant or if this does not belong as a
> 9.6 open item, please let us know. Otherwise, please observe the policy on
> open item ownership[1] and send a status update within 72 hours of this
> message. Include a date for your subsequent status update. Testers may
> discover new open items at any time, and I want to plan to get them all fixed
> well in advance of shipping 9.6rc1. Consequently, I will appreciate your
> efforts toward speedy resolution. Thanks.
>
> [1] http://www.postgresql.org/message-id/20160527025039.GA447393@tornado.leadboat.com
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. Also, I would appreciate a
clearer explanation of why this only affects CLUSTER tuplesorts.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company