On Fri, Jul 1, 2016 at 12:06 AM, Noah Misch <n...@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.ga447...@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

Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:

Reply via email to