| From: | Peter Geoghegan <peter(at)2ndquadrant(dot)com> |
|---|---|
| To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
| Cc: | Simon Riggs <simon(at)2ndquadrant(dot)com>, Jeff Janes <jeff(dot)janes(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>, Greg S <stark(at)mit(dot)edu> |
| Subject: | Re: tuplesort memory usage: grow_memtuples |
| Date: | 2012-11-15 19:13:58 |
| Message-ID: | CAEYLb_XB0kVy-x4wt31bQgHan-Stvfzvchy-Q-XdJ-S_8XfxOg@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On 15 November 2012 18:13, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
> Ah, yeah. I wondered in passing about that but forgot to follow up on
> it. The problem specifically is that the intermediate result
> memtupsize * newmemtuples might overflow. I believe that the old
> memtupsize can never be more than 2^26 bytes, because the allocation
> limit is 1GB and each SortTuple is 16 bytes.
Do you mean the intermediate result of memtupsize * allowedMem? Oh,
yeah, that could overflow rather easily on a platform where long is
only 32-bit. We're multiplying the entire current allocation size of
the array by the maximum length. I guess the fact that you didn't spot
it made me overconfident. :-)
--
Peter Geoghegan http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training and Services
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Robert Haas | 2012-11-15 19:16:34 | Re: tuplesort memory usage: grow_memtuples |
| Previous Message | Robert Haas | 2012-11-15 19:13:13 | Re: WIP patch: add (PRE|POST)PROCESSOR options to COPY |