| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Peter Geoghegan <pg(at)bowt(dot)ie> |
| Cc: | Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>, Andres Freund <andres(at)anarazel(dot)de>, "Vitaly V(dot) Voronov" <wizard_1024(at)tut(dot)by>, PostgreSQL mailing lists <pgsql-bugs(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: BUG #15144: *** glibc detected *** postgres: postgres smsconsole [local] SELECT: double free or corruption (!pre |
| Date: | 2018-04-16 22:21:06 |
| Message-ID: | 1155.1523917266@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-bugs |
Peter Geoghegan <pg(at)bowt(dot)ie> writes:
> On Mon, Apr 16, 2018 at 1:56 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> BTW, I notice that in this situation, readtup_heap seems to be
>> palloc'ing in the caller's context, but it counts the memory as
>> if it were in the tuplestore's context. Somebody's confused there.
> I could just kick myself for not going through tuplestore (and its
> version of readtup_heap) as part of the 90decdba3 work.
Yeah, I should have thought to question that too. tuplestore was
originally built by stripping down tuplesort, and at least in the
beginning, I'm pretty sure that all these semantic API details were
the same. We should likely have made more effort to keep them in
sync. (Still, until we've proven that there *is* a bug here,
let's not kick ourselves too hard.)
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Peter Geoghegan | 2018-04-16 22:46:03 | Re: BUG #15144: *** glibc detected *** postgres: postgres smsconsole [local] SELECT: double free or corruption (!pre |
| Previous Message | Peter Geoghegan | 2018-04-16 22:13:24 | Re: BUG #15144: *** glibc detected *** postgres: postgres smsconsole [local] SELECT: double free or corruption (!pre |