2002-07-19 19:35:11 +02:00
|
|
|
/*
|
2006-10-04 00:18:23 +02:00
|
|
|
* qsort.c: standard quicksort algorithm
|
|
|
|
*
|
2004-10-05 02:12:49 +02:00
|
|
|
* Modifications from vanilla NetBSD source:
|
|
|
|
* Add do ... while() macro fix
|
|
|
|
* Remove __inline, _DIAGASSERTs, __P
|
2006-03-21 20:49:15 +01:00
|
|
|
* Remove ill-considered "swap_cnt" switch to insertion sort,
|
|
|
|
* in favor of a simple check for presorted input.
|
Fix a low-probability crash in our qsort implementation.
It's standard for quicksort implementations, after having partitioned the
input into two subgroups, to recurse to process the smaller partition and
then handle the larger partition by iterating. This method guarantees
that no more than log2(N) levels of recursion can be needed. However,
Bentley and McIlroy argued that checking to see which partition is smaller
isn't worth the cycles, and so their code doesn't do that but just always
recurses on the left partition. In most cases that's fine; but with
worst-case input we might need O(N) levels of recursion, and that means
that qsort could be driven to stack overflow. Such an overflow seems to
be the only explanation for today's report from Yiqing Jin of a SIGSEGV
in med3_tuple while creating an index of a couple billion entries with a
very large maintenance_work_mem setting. Therefore, let's spend the few
additional cycles and lines of code needed to choose the smaller partition
for recursion.
Also, fix up the qsort code so that it properly uses size_t not int for
some intermediate values representing numbers of items. This would only
be a live risk when sorting more than INT_MAX bytes (in qsort/qsort_arg)
or tuples (in qsort_tuple), which I believe would never happen with any
caller in the current core code --- but perhaps it could happen with
call sites in third-party modules? In any case, this is trouble waiting
to happen, and the corrected code is probably if anything shorter and
faster than before, since it removes sign-extension steps that had to
happen when converting between int and size_t.
In passing, move a couple of CHECK_FOR_INTERRUPTS() calls so that it's
not necessary to preserve the value of "r" across them, and prettify
the output of gen_qsort_tuple.pl a little.
Back-patch to all supported branches. The odds of hitting this issue
are probably higher in 9.4 and up than before, due to the new ability
to allocate sort workspaces exceeding 1GB, but there's no good reason
to believe that it's impossible to crash older branches this way.
2015-07-17 04:57:46 +02:00
|
|
|
* Take care to recurse on the smaller partition, to bound stack usage.
|
2002-08-12 17:24:07 +02:00
|
|
|
*
|
2012-02-15 18:13:32 +01:00
|
|
|
* CAUTION: if you change this file, see also qsort_arg.c, gen_qsort_tuple.pl
|
2006-10-04 00:18:23 +02:00
|
|
|
*
|
2010-09-20 22:08:53 +02:00
|
|
|
* src/port/qsort.c
|
2002-07-19 19:35:11 +02:00
|
|
|
*/
|
|
|
|
|
2004-10-05 02:12:49 +02:00
|
|
|
/* $NetBSD: qsort.c,v 1.13 2003/08/07 16:43:42 agc Exp $ */
|
2002-07-19 19:35:11 +02:00
|
|
|
|
|
|
|
/*-
|
|
|
|
* Copyright (c) 1992, 1993
|
|
|
|
* The Regents of the University of California. All rights reserved.
|
|
|
|
*
|
|
|
|
* Redistribution and use in source and binary forms, with or without
|
|
|
|
* modification, are permitted provided that the following conditions
|
|
|
|
* are met:
|
|
|
|
* 1. Redistributions of source code must retain the above copyright
|
2005-10-15 04:49:52 +02:00
|
|
|
* notice, this list of conditions and the following disclaimer.
|
2002-07-19 19:35:11 +02:00
|
|
|
* 2. Redistributions in binary form must reproduce the above copyright
|
2005-10-15 04:49:52 +02:00
|
|
|
* notice, this list of conditions and the following disclaimer in the
|
|
|
|
* documentation and/or other materials provided with the distribution.
|
2004-10-05 02:12:49 +02:00
|
|
|
* 3. Neither the name of the University nor the names of its contributors
|
2005-10-15 04:49:52 +02:00
|
|
|
* may be used to endorse or promote products derived from this software
|
|
|
|
* without specific prior written permission.
|
2002-07-19 19:35:11 +02:00
|
|
|
*
|
|
|
|
* THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND
|
|
|
|
* ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
|
|
|
|
* IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
|
2014-05-06 18:12:18 +02:00
|
|
|
* ARE DISCLAIMED. IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE
|
2002-07-19 19:35:11 +02:00
|
|
|
* FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
|
|
|
|
* DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
|
|
|
|
* OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
|
|
|
|
* HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
|
|
|
|
* LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
|
|
|
|
* OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
|
|
|
|
* SUCH DAMAGE.
|
|
|
|
*/
|
|
|
|
|
2005-07-28 06:03:14 +02:00
|
|
|
#include "c.h"
|
2002-07-19 19:35:11 +02:00
|
|
|
|
|
|
|
|
2006-10-19 22:56:22 +02:00
|
|
|
static char *med3(char *a, char *b, char *c,
|
2019-05-22 19:04:48 +02:00
|
|
|
int (*cmp) (const void *, const void *));
|
2002-09-04 22:31:48 +02:00
|
|
|
static void swapfunc(char *, char *, size_t, int);
|
2002-07-19 19:35:11 +02:00
|
|
|
|
|
|
|
/*
|
2006-03-21 20:49:15 +01:00
|
|
|
* Qsort routine based on J. L. Bentley and M. D. McIlroy,
|
|
|
|
* "Engineering a sort function",
|
|
|
|
* Software--Practice and Experience 23 (1993) 1249-1265.
|
Fix a low-probability crash in our qsort implementation.
It's standard for quicksort implementations, after having partitioned the
input into two subgroups, to recurse to process the smaller partition and
then handle the larger partition by iterating. This method guarantees
that no more than log2(N) levels of recursion can be needed. However,
Bentley and McIlroy argued that checking to see which partition is smaller
isn't worth the cycles, and so their code doesn't do that but just always
recurses on the left partition. In most cases that's fine; but with
worst-case input we might need O(N) levels of recursion, and that means
that qsort could be driven to stack overflow. Such an overflow seems to
be the only explanation for today's report from Yiqing Jin of a SIGSEGV
in med3_tuple while creating an index of a couple billion entries with a
very large maintenance_work_mem setting. Therefore, let's spend the few
additional cycles and lines of code needed to choose the smaller partition
for recursion.
Also, fix up the qsort code so that it properly uses size_t not int for
some intermediate values representing numbers of items. This would only
be a live risk when sorting more than INT_MAX bytes (in qsort/qsort_arg)
or tuples (in qsort_tuple), which I believe would never happen with any
caller in the current core code --- but perhaps it could happen with
call sites in third-party modules? In any case, this is trouble waiting
to happen, and the corrected code is probably if anything shorter and
faster than before, since it removes sign-extension steps that had to
happen when converting between int and size_t.
In passing, move a couple of CHECK_FOR_INTERRUPTS() calls so that it's
not necessary to preserve the value of "r" across them, and prettify
the output of gen_qsort_tuple.pl a little.
Back-patch to all supported branches. The odds of hitting this issue
are probably higher in 9.4 and up than before, due to the new ability
to allocate sort workspaces exceeding 1GB, but there's no good reason
to believe that it's impossible to crash older branches this way.
2015-07-17 04:57:46 +02:00
|
|
|
*
|
2006-03-21 20:49:15 +01:00
|
|
|
* We have modified their original by adding a check for already-sorted input,
|
|
|
|
* which seems to be a win per discussions on pgsql-hackers around 2006-03-21.
|
Fix a low-probability crash in our qsort implementation.
It's standard for quicksort implementations, after having partitioned the
input into two subgroups, to recurse to process the smaller partition and
then handle the larger partition by iterating. This method guarantees
that no more than log2(N) levels of recursion can be needed. However,
Bentley and McIlroy argued that checking to see which partition is smaller
isn't worth the cycles, and so their code doesn't do that but just always
recurses on the left partition. In most cases that's fine; but with
worst-case input we might need O(N) levels of recursion, and that means
that qsort could be driven to stack overflow. Such an overflow seems to
be the only explanation for today's report from Yiqing Jin of a SIGSEGV
in med3_tuple while creating an index of a couple billion entries with a
very large maintenance_work_mem setting. Therefore, let's spend the few
additional cycles and lines of code needed to choose the smaller partition
for recursion.
Also, fix up the qsort code so that it properly uses size_t not int for
some intermediate values representing numbers of items. This would only
be a live risk when sorting more than INT_MAX bytes (in qsort/qsort_arg)
or tuples (in qsort_tuple), which I believe would never happen with any
caller in the current core code --- but perhaps it could happen with
call sites in third-party modules? In any case, this is trouble waiting
to happen, and the corrected code is probably if anything shorter and
faster than before, since it removes sign-extension steps that had to
happen when converting between int and size_t.
In passing, move a couple of CHECK_FOR_INTERRUPTS() calls so that it's
not necessary to preserve the value of "r" across them, and prettify
the output of gen_qsort_tuple.pl a little.
Back-patch to all supported branches. The odds of hitting this issue
are probably higher in 9.4 and up than before, due to the new ability
to allocate sort workspaces exceeding 1GB, but there's no good reason
to believe that it's impossible to crash older branches this way.
2015-07-17 04:57:46 +02:00
|
|
|
*
|
|
|
|
* Also, we recurse on the smaller partition and iterate on the larger one,
|
|
|
|
* which ensures we cannot recurse more than log(N) levels (since the
|
|
|
|
* partition recursed to is surely no more than half of the input). Bentley
|
|
|
|
* and McIlroy explicitly rejected doing this on the grounds that it's "not
|
|
|
|
* worth the effort", but we have seen crashes in the field due to stack
|
|
|
|
* overrun, so that judgment seems wrong.
|
2002-07-19 19:35:11 +02:00
|
|
|
*/
|
Fix a low-probability crash in our qsort implementation.
It's standard for quicksort implementations, after having partitioned the
input into two subgroups, to recurse to process the smaller partition and
then handle the larger partition by iterating. This method guarantees
that no more than log2(N) levels of recursion can be needed. However,
Bentley and McIlroy argued that checking to see which partition is smaller
isn't worth the cycles, and so their code doesn't do that but just always
recurses on the left partition. In most cases that's fine; but with
worst-case input we might need O(N) levels of recursion, and that means
that qsort could be driven to stack overflow. Such an overflow seems to
be the only explanation for today's report from Yiqing Jin of a SIGSEGV
in med3_tuple while creating an index of a couple billion entries with a
very large maintenance_work_mem setting. Therefore, let's spend the few
additional cycles and lines of code needed to choose the smaller partition
for recursion.
Also, fix up the qsort code so that it properly uses size_t not int for
some intermediate values representing numbers of items. This would only
be a live risk when sorting more than INT_MAX bytes (in qsort/qsort_arg)
or tuples (in qsort_tuple), which I believe would never happen with any
caller in the current core code --- but perhaps it could happen with
call sites in third-party modules? In any case, this is trouble waiting
to happen, and the corrected code is probably if anything shorter and
faster than before, since it removes sign-extension steps that had to
happen when converting between int and size_t.
In passing, move a couple of CHECK_FOR_INTERRUPTS() calls so that it's
not necessary to preserve the value of "r" across them, and prettify
the output of gen_qsort_tuple.pl a little.
Back-patch to all supported branches. The odds of hitting this issue
are probably higher in 9.4 and up than before, due to the new ability
to allocate sort workspaces exceeding 1GB, but there's no good reason
to believe that it's impossible to crash older branches this way.
2015-07-17 04:57:46 +02:00
|
|
|
|
2002-07-19 19:35:11 +02:00
|
|
|
#define swapcode(TYPE, parmi, parmj, n) \
|
|
|
|
do { \
|
|
|
|
size_t i = (n) / sizeof (TYPE); \
|
|
|
|
TYPE *pi = (TYPE *)(void *)(parmi); \
|
|
|
|
TYPE *pj = (TYPE *)(void *)(parmj); \
|
|
|
|
do { \
|
|
|
|
TYPE t = *pi; \
|
|
|
|
*pi++ = *pj; \
|
|
|
|
*pj++ = t; \
|
|
|
|
} while (--i > 0); \
|
|
|
|
} while (0)
|
|
|
|
|
2005-05-25 23:40:43 +02:00
|
|
|
#define SWAPINIT(a, es) swaptype = ((char *)(a) - (char *)0) % sizeof(long) || \
|
|
|
|
(es) % sizeof(long) ? 2 : (es) == sizeof(long)? 0 : 1;
|
2002-07-19 19:35:11 +02:00
|
|
|
|
|
|
|
static void
|
2007-03-18 06:36:50 +01:00
|
|
|
swapfunc(char *a, char *b, size_t n, int swaptype)
|
2002-07-19 19:35:11 +02:00
|
|
|
{
|
|
|
|
if (swaptype <= 1)
|
|
|
|
swapcode(long, a, b, n);
|
|
|
|
else
|
|
|
|
swapcode(char, a, b, n);
|
|
|
|
}
|
|
|
|
|
|
|
|
#define swap(a, b) \
|
|
|
|
if (swaptype == 0) { \
|
|
|
|
long t = *(long *)(void *)(a); \
|
|
|
|
*(long *)(void *)(a) = *(long *)(void *)(b); \
|
|
|
|
*(long *)(void *)(b) = t; \
|
|
|
|
} else \
|
|
|
|
swapfunc(a, b, es, swaptype)
|
|
|
|
|
Fix a low-probability crash in our qsort implementation.
It's standard for quicksort implementations, after having partitioned the
input into two subgroups, to recurse to process the smaller partition and
then handle the larger partition by iterating. This method guarantees
that no more than log2(N) levels of recursion can be needed. However,
Bentley and McIlroy argued that checking to see which partition is smaller
isn't worth the cycles, and so their code doesn't do that but just always
recurses on the left partition. In most cases that's fine; but with
worst-case input we might need O(N) levels of recursion, and that means
that qsort could be driven to stack overflow. Such an overflow seems to
be the only explanation for today's report from Yiqing Jin of a SIGSEGV
in med3_tuple while creating an index of a couple billion entries with a
very large maintenance_work_mem setting. Therefore, let's spend the few
additional cycles and lines of code needed to choose the smaller partition
for recursion.
Also, fix up the qsort code so that it properly uses size_t not int for
some intermediate values representing numbers of items. This would only
be a live risk when sorting more than INT_MAX bytes (in qsort/qsort_arg)
or tuples (in qsort_tuple), which I believe would never happen with any
caller in the current core code --- but perhaps it could happen with
call sites in third-party modules? In any case, this is trouble waiting
to happen, and the corrected code is probably if anything shorter and
faster than before, since it removes sign-extension steps that had to
happen when converting between int and size_t.
In passing, move a couple of CHECK_FOR_INTERRUPTS() calls so that it's
not necessary to preserve the value of "r" across them, and prettify
the output of gen_qsort_tuple.pl a little.
Back-patch to all supported branches. The odds of hitting this issue
are probably higher in 9.4 and up than before, due to the new ability
to allocate sort workspaces exceeding 1GB, but there's no good reason
to believe that it's impossible to crash older branches this way.
2015-07-17 04:57:46 +02:00
|
|
|
#define vecswap(a, b, n) if ((n) > 0) swapfunc(a, b, n, swaptype)
|
2002-07-19 19:35:11 +02:00
|
|
|
|
|
|
|
static char *
|
2006-10-19 22:56:22 +02:00
|
|
|
med3(char *a, char *b, char *c, int (*cmp) (const void *, const void *))
|
2002-07-19 19:35:11 +02:00
|
|
|
{
|
|
|
|
return cmp(a, b) < 0 ?
|
|
|
|
(cmp(b, c) < 0 ? b : (cmp(a, c) < 0 ? c : a))
|
|
|
|
: (cmp(b, c) > 0 ? b : (cmp(a, c) < 0 ? a : c));
|
|
|
|
}
|
|
|
|
|
|
|
|
void
|
2006-10-19 22:56:22 +02:00
|
|
|
pg_qsort(void *a, size_t n, size_t es, int (*cmp) (const void *, const void *))
|
2002-07-19 19:35:11 +02:00
|
|
|
{
|
|
|
|
char *pa,
|
|
|
|
*pb,
|
|
|
|
*pc,
|
|
|
|
*pd,
|
|
|
|
*pl,
|
|
|
|
*pm,
|
|
|
|
*pn;
|
Fix a low-probability crash in our qsort implementation.
It's standard for quicksort implementations, after having partitioned the
input into two subgroups, to recurse to process the smaller partition and
then handle the larger partition by iterating. This method guarantees
that no more than log2(N) levels of recursion can be needed. However,
Bentley and McIlroy argued that checking to see which partition is smaller
isn't worth the cycles, and so their code doesn't do that but just always
recurses on the left partition. In most cases that's fine; but with
worst-case input we might need O(N) levels of recursion, and that means
that qsort could be driven to stack overflow. Such an overflow seems to
be the only explanation for today's report from Yiqing Jin of a SIGSEGV
in med3_tuple while creating an index of a couple billion entries with a
very large maintenance_work_mem setting. Therefore, let's spend the few
additional cycles and lines of code needed to choose the smaller partition
for recursion.
Also, fix up the qsort code so that it properly uses size_t not int for
some intermediate values representing numbers of items. This would only
be a live risk when sorting more than INT_MAX bytes (in qsort/qsort_arg)
or tuples (in qsort_tuple), which I believe would never happen with any
caller in the current core code --- but perhaps it could happen with
call sites in third-party modules? In any case, this is trouble waiting
to happen, and the corrected code is probably if anything shorter and
faster than before, since it removes sign-extension steps that had to
happen when converting between int and size_t.
In passing, move a couple of CHECK_FOR_INTERRUPTS() calls so that it's
not necessary to preserve the value of "r" across them, and prettify
the output of gen_qsort_tuple.pl a little.
Back-patch to all supported branches. The odds of hitting this issue
are probably higher in 9.4 and up than before, due to the new ability
to allocate sort workspaces exceeding 1GB, but there's no good reason
to believe that it's impossible to crash older branches this way.
2015-07-17 04:57:46 +02:00
|
|
|
size_t d1,
|
|
|
|
d2;
|
|
|
|
int r,
|
2002-07-19 19:35:11 +02:00
|
|
|
swaptype,
|
2006-03-21 20:49:15 +01:00
|
|
|
presorted;
|
2002-07-19 19:35:11 +02:00
|
|
|
|
|
|
|
loop:SWAPINIT(a, es);
|
|
|
|
if (n < 7)
|
|
|
|
{
|
|
|
|
for (pm = (char *) a + es; pm < (char *) a + n * es; pm += es)
|
|
|
|
for (pl = pm; pl > (char *) a && cmp(pl - es, pl) > 0;
|
|
|
|
pl -= es)
|
|
|
|
swap(pl, pl - es);
|
|
|
|
return;
|
|
|
|
}
|
2006-03-21 20:49:15 +01:00
|
|
|
presorted = 1;
|
|
|
|
for (pm = (char *) a + es; pm < (char *) a + n * es; pm += es)
|
|
|
|
{
|
|
|
|
if (cmp(pm - es, pm) > 0)
|
|
|
|
{
|
|
|
|
presorted = 0;
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
if (presorted)
|
|
|
|
return;
|
2002-07-19 19:35:11 +02:00
|
|
|
pm = (char *) a + (n / 2) * es;
|
|
|
|
if (n > 7)
|
|
|
|
{
|
|
|
|
pl = (char *) a;
|
|
|
|
pn = (char *) a + (n - 1) * es;
|
|
|
|
if (n > 40)
|
|
|
|
{
|
Fix a low-probability crash in our qsort implementation.
It's standard for quicksort implementations, after having partitioned the
input into two subgroups, to recurse to process the smaller partition and
then handle the larger partition by iterating. This method guarantees
that no more than log2(N) levels of recursion can be needed. However,
Bentley and McIlroy argued that checking to see which partition is smaller
isn't worth the cycles, and so their code doesn't do that but just always
recurses on the left partition. In most cases that's fine; but with
worst-case input we might need O(N) levels of recursion, and that means
that qsort could be driven to stack overflow. Such an overflow seems to
be the only explanation for today's report from Yiqing Jin of a SIGSEGV
in med3_tuple while creating an index of a couple billion entries with a
very large maintenance_work_mem setting. Therefore, let's spend the few
additional cycles and lines of code needed to choose the smaller partition
for recursion.
Also, fix up the qsort code so that it properly uses size_t not int for
some intermediate values representing numbers of items. This would only
be a live risk when sorting more than INT_MAX bytes (in qsort/qsort_arg)
or tuples (in qsort_tuple), which I believe would never happen with any
caller in the current core code --- but perhaps it could happen with
call sites in third-party modules? In any case, this is trouble waiting
to happen, and the corrected code is probably if anything shorter and
faster than before, since it removes sign-extension steps that had to
happen when converting between int and size_t.
In passing, move a couple of CHECK_FOR_INTERRUPTS() calls so that it's
not necessary to preserve the value of "r" across them, and prettify
the output of gen_qsort_tuple.pl a little.
Back-patch to all supported branches. The odds of hitting this issue
are probably higher in 9.4 and up than before, due to the new ability
to allocate sort workspaces exceeding 1GB, but there's no good reason
to believe that it's impossible to crash older branches this way.
2015-07-17 04:57:46 +02:00
|
|
|
size_t d = (n / 8) * es;
|
|
|
|
|
2002-07-19 19:35:11 +02:00
|
|
|
pl = med3(pl, pl + d, pl + 2 * d, cmp);
|
|
|
|
pm = med3(pm - d, pm, pm + d, cmp);
|
|
|
|
pn = med3(pn - 2 * d, pn - d, pn, cmp);
|
|
|
|
}
|
|
|
|
pm = med3(pl, pm, pn, cmp);
|
|
|
|
}
|
|
|
|
swap(a, pm);
|
|
|
|
pa = pb = (char *) a + es;
|
|
|
|
pc = pd = (char *) a + (n - 1) * es;
|
|
|
|
for (;;)
|
|
|
|
{
|
|
|
|
while (pb <= pc && (r = cmp(pb, a)) <= 0)
|
|
|
|
{
|
|
|
|
if (r == 0)
|
|
|
|
{
|
|
|
|
swap(pa, pb);
|
|
|
|
pa += es;
|
|
|
|
}
|
|
|
|
pb += es;
|
|
|
|
}
|
|
|
|
while (pb <= pc && (r = cmp(pc, a)) >= 0)
|
|
|
|
{
|
|
|
|
if (r == 0)
|
|
|
|
{
|
|
|
|
swap(pc, pd);
|
|
|
|
pd -= es;
|
|
|
|
}
|
|
|
|
pc -= es;
|
|
|
|
}
|
|
|
|
if (pb > pc)
|
|
|
|
break;
|
|
|
|
swap(pb, pc);
|
|
|
|
pb += es;
|
|
|
|
pc -= es;
|
|
|
|
}
|
|
|
|
pn = (char *) a + n * es;
|
Fix a low-probability crash in our qsort implementation.
It's standard for quicksort implementations, after having partitioned the
input into two subgroups, to recurse to process the smaller partition and
then handle the larger partition by iterating. This method guarantees
that no more than log2(N) levels of recursion can be needed. However,
Bentley and McIlroy argued that checking to see which partition is smaller
isn't worth the cycles, and so their code doesn't do that but just always
recurses on the left partition. In most cases that's fine; but with
worst-case input we might need O(N) levels of recursion, and that means
that qsort could be driven to stack overflow. Such an overflow seems to
be the only explanation for today's report from Yiqing Jin of a SIGSEGV
in med3_tuple while creating an index of a couple billion entries with a
very large maintenance_work_mem setting. Therefore, let's spend the few
additional cycles and lines of code needed to choose the smaller partition
for recursion.
Also, fix up the qsort code so that it properly uses size_t not int for
some intermediate values representing numbers of items. This would only
be a live risk when sorting more than INT_MAX bytes (in qsort/qsort_arg)
or tuples (in qsort_tuple), which I believe would never happen with any
caller in the current core code --- but perhaps it could happen with
call sites in third-party modules? In any case, this is trouble waiting
to happen, and the corrected code is probably if anything shorter and
faster than before, since it removes sign-extension steps that had to
happen when converting between int and size_t.
In passing, move a couple of CHECK_FOR_INTERRUPTS() calls so that it's
not necessary to preserve the value of "r" across them, and prettify
the output of gen_qsort_tuple.pl a little.
Back-patch to all supported branches. The odds of hitting this issue
are probably higher in 9.4 and up than before, due to the new ability
to allocate sort workspaces exceeding 1GB, but there's no good reason
to believe that it's impossible to crash older branches this way.
2015-07-17 04:57:46 +02:00
|
|
|
d1 = Min(pa - (char *) a, pb - pa);
|
|
|
|
vecswap(a, pb - d1, d1);
|
|
|
|
d1 = Min(pd - pc, pn - pd - es);
|
|
|
|
vecswap(pb, pn - d1, d1);
|
|
|
|
d1 = pb - pa;
|
|
|
|
d2 = pd - pc;
|
|
|
|
if (d1 <= d2)
|
2002-07-19 19:35:11 +02:00
|
|
|
{
|
Fix a low-probability crash in our qsort implementation.
It's standard for quicksort implementations, after having partitioned the
input into two subgroups, to recurse to process the smaller partition and
then handle the larger partition by iterating. This method guarantees
that no more than log2(N) levels of recursion can be needed. However,
Bentley and McIlroy argued that checking to see which partition is smaller
isn't worth the cycles, and so their code doesn't do that but just always
recurses on the left partition. In most cases that's fine; but with
worst-case input we might need O(N) levels of recursion, and that means
that qsort could be driven to stack overflow. Such an overflow seems to
be the only explanation for today's report from Yiqing Jin of a SIGSEGV
in med3_tuple while creating an index of a couple billion entries with a
very large maintenance_work_mem setting. Therefore, let's spend the few
additional cycles and lines of code needed to choose the smaller partition
for recursion.
Also, fix up the qsort code so that it properly uses size_t not int for
some intermediate values representing numbers of items. This would only
be a live risk when sorting more than INT_MAX bytes (in qsort/qsort_arg)
or tuples (in qsort_tuple), which I believe would never happen with any
caller in the current core code --- but perhaps it could happen with
call sites in third-party modules? In any case, this is trouble waiting
to happen, and the corrected code is probably if anything shorter and
faster than before, since it removes sign-extension steps that had to
happen when converting between int and size_t.
In passing, move a couple of CHECK_FOR_INTERRUPTS() calls so that it's
not necessary to preserve the value of "r" across them, and prettify
the output of gen_qsort_tuple.pl a little.
Back-patch to all supported branches. The odds of hitting this issue
are probably higher in 9.4 and up than before, due to the new ability
to allocate sort workspaces exceeding 1GB, but there's no good reason
to believe that it's impossible to crash older branches this way.
2015-07-17 04:57:46 +02:00
|
|
|
/* Recurse on left partition, then iterate on right partition */
|
|
|
|
if (d1 > es)
|
|
|
|
pg_qsort(a, d1 / es, es, cmp);
|
|
|
|
if (d2 > es)
|
|
|
|
{
|
|
|
|
/* Iterate rather than recurse to save stack space */
|
|
|
|
/* pg_qsort(pn - d2, d2 / es, es, cmp); */
|
|
|
|
a = pn - d2;
|
|
|
|
n = d2 / es;
|
|
|
|
goto loop;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
else
|
|
|
|
{
|
|
|
|
/* Recurse on right partition, then iterate on left partition */
|
|
|
|
if (d2 > es)
|
|
|
|
pg_qsort(pn - d2, d2 / es, es, cmp);
|
|
|
|
if (d1 > es)
|
|
|
|
{
|
|
|
|
/* Iterate rather than recurse to save stack space */
|
|
|
|
/* pg_qsort(a, d1 / es, es, cmp); */
|
|
|
|
n = d1 / es;
|
|
|
|
goto loop;
|
|
|
|
}
|
2002-07-19 19:35:11 +02:00
|
|
|
}
|
|
|
|
}
|
2012-07-20 17:38:47 +02:00
|
|
|
|
|
|
|
/*
|
Fix a low-probability crash in our qsort implementation.
It's standard for quicksort implementations, after having partitioned the
input into two subgroups, to recurse to process the smaller partition and
then handle the larger partition by iterating. This method guarantees
that no more than log2(N) levels of recursion can be needed. However,
Bentley and McIlroy argued that checking to see which partition is smaller
isn't worth the cycles, and so their code doesn't do that but just always
recurses on the left partition. In most cases that's fine; but with
worst-case input we might need O(N) levels of recursion, and that means
that qsort could be driven to stack overflow. Such an overflow seems to
be the only explanation for today's report from Yiqing Jin of a SIGSEGV
in med3_tuple while creating an index of a couple billion entries with a
very large maintenance_work_mem setting. Therefore, let's spend the few
additional cycles and lines of code needed to choose the smaller partition
for recursion.
Also, fix up the qsort code so that it properly uses size_t not int for
some intermediate values representing numbers of items. This would only
be a live risk when sorting more than INT_MAX bytes (in qsort/qsort_arg)
or tuples (in qsort_tuple), which I believe would never happen with any
caller in the current core code --- but perhaps it could happen with
call sites in third-party modules? In any case, this is trouble waiting
to happen, and the corrected code is probably if anything shorter and
faster than before, since it removes sign-extension steps that had to
happen when converting between int and size_t.
In passing, move a couple of CHECK_FOR_INTERRUPTS() calls so that it's
not necessary to preserve the value of "r" across them, and prettify
the output of gen_qsort_tuple.pl a little.
Back-patch to all supported branches. The odds of hitting this issue
are probably higher in 9.4 and up than before, due to the new ability
to allocate sort workspaces exceeding 1GB, but there's no good reason
to believe that it's impossible to crash older branches this way.
2015-07-17 04:57:46 +02:00
|
|
|
* qsort comparator wrapper for strcmp.
|
2012-07-20 17:38:47 +02:00
|
|
|
*/
|
|
|
|
int
|
|
|
|
pg_qsort_strcmp(const void *a, const void *b)
|
|
|
|
{
|
Fix a low-probability crash in our qsort implementation.
It's standard for quicksort implementations, after having partitioned the
input into two subgroups, to recurse to process the smaller partition and
then handle the larger partition by iterating. This method guarantees
that no more than log2(N) levels of recursion can be needed. However,
Bentley and McIlroy argued that checking to see which partition is smaller
isn't worth the cycles, and so their code doesn't do that but just always
recurses on the left partition. In most cases that's fine; but with
worst-case input we might need O(N) levels of recursion, and that means
that qsort could be driven to stack overflow. Such an overflow seems to
be the only explanation for today's report from Yiqing Jin of a SIGSEGV
in med3_tuple while creating an index of a couple billion entries with a
very large maintenance_work_mem setting. Therefore, let's spend the few
additional cycles and lines of code needed to choose the smaller partition
for recursion.
Also, fix up the qsort code so that it properly uses size_t not int for
some intermediate values representing numbers of items. This would only
be a live risk when sorting more than INT_MAX bytes (in qsort/qsort_arg)
or tuples (in qsort_tuple), which I believe would never happen with any
caller in the current core code --- but perhaps it could happen with
call sites in third-party modules? In any case, this is trouble waiting
to happen, and the corrected code is probably if anything shorter and
faster than before, since it removes sign-extension steps that had to
happen when converting between int and size_t.
In passing, move a couple of CHECK_FOR_INTERRUPTS() calls so that it's
not necessary to preserve the value of "r" across them, and prettify
the output of gen_qsort_tuple.pl a little.
Back-patch to all supported branches. The odds of hitting this issue
are probably higher in 9.4 and up than before, due to the new ability
to allocate sort workspaces exceeding 1GB, but there's no good reason
to believe that it's impossible to crash older branches this way.
2015-07-17 04:57:46 +02:00
|
|
|
return strcmp(*(const char *const *) a, *(const char *const *) b);
|
2012-07-20 17:38:47 +02:00
|
|
|
}
|