Tatsuo Ishii <[EMAIL PROTECTED]> writes: > Kenji Sugita has identified a problem with cost_sort() in costsize.c. > In the following code fragment, sortmembytes is defined as long. So > double nruns = nbytes / (sortmembytes * 2); > may cause an integer overflow if sortmembytes exceeds 2^30, which in > turn make optimizer to produce wrong query plan(this actually happned > in a large PostgreSQL installation which has tons of memory).
I find it really really hard to believe that it's wise to run with sort_mem exceeding 2 gig ;-). Does that installation have so much RAM that it can afford to run multiple many-Gb sorts concurrently? This is far from being the only place that multiplies SortMem by 1024. My inclination is that a safer fix is to alter guc.c's entry for SortMem to establish a maximum value of INT_MAX/1024 for the variable. Probably some of the other GUC variables like shared_buffers ought to have overflow-related maxima established, too. regards, tom lane ---------------------------(end of broadcast)--------------------------- TIP 4: Don't 'kill -9' the postmaster