From: | Noah Misch <noah(at)leadboat(dot)com> |
---|---|
To: | robertmhaas(at)gmail(dot)com |
Cc: | Peter Geoghegan <pg(at)heroku(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Bug in batch tuplesort memory CLUSTER case (9.6 only) |
Date: | 2016-07-01 04:06:08 |
Message-ID: | 20160701040608.GB1426591@tornado.leadboat.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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
From | Date | Subject | |
---|---|---|---|
Next Message | Thomas Munro | 2016-07-01 04:08:10 | Re: [sqlsmith] crashes in RestoreSnapshot on hot standby |
Previous Message | Tsunakawa, Takayuki | 2016-07-01 04:00:53 | Re: Is a UDF binary portable across different minor releases and PostgreSQL distributions? |