Thread

Commits

  1. Fix dereference of dangling pointer in GiST index buffering build.

  1. BUG #17874: Incorrect memory access at gistBuildCallback

    The Post Office <noreply@postgresql.org> — 2023-03-28T16:01:01Z

    The following bug has been logged on the website:
    
    Bug reference:      17874
    Logged by:          Egor Chindyaskin
    Email address:      kyzevan23@mail.ru
    PostgreSQL version: 15.2
    Operating system:   Ubuntu 22.04
    Description:        
    
    With a server compiled with flag -DUSE_VALGRIND the following query:
    
    create table test(a int4, b point);
    
    create index test_index on test using gist(b) with (buffering = on,
    fillfactor=50);
    drop index test_index;
    insert into test (a, b) select g, point(g*10, g*10) from generate_series(1,
    10000) g;
    vacuum analyze test;
    
    create index test_index on test using gist(b) with (buffering = on,
    fillfactor=50);
    drop index test_index;
    insert into test (a, b) select g, point(g*10, g*10) from generate_series(1,
    10000) g;
    vacuum analyze test;
    
    create index test_index on test using gist(b) with (buffering = on,
    fillfactor=50);
    drop index test_index;
    insert into test (a, b) select g, point(g*10, g*10) from generate_series(1,
    10000) g;
    vacuum analyze test;
    
    create index test_index on test using gist(b) with (buffering = on,
    fillfactor=50);
    drop index test_index;
    insert into test (a, b) select g, point(g*10, g*10) from generate_series(1,
    10000) g;
    vacuum analyze test;
    
    causes an incorrect memory access:
    
    ==00:00:00:20.465 256552== Invalid read of size 2
    ==00:00:00:20.465 256552==    at 0x20EE4F: gistBuildCallback
    (gistbuild.c:921)
    ==00:00:00:20.465 256552==    by 0x241838: heapam_index_build_range_scan
    (heapam_handler.c:1794)
    ==00:00:00:20.465 256552==    by 0x20F308: table_index_build_scan
    (tableam.h:1791)
    ==00:00:00:20.465 256552==    by 0x20F308: gistbuild (gistbuild.c:317)
    ==00:00:00:20.465 256552==    by 0x2DC8A9: index_build (index.c:3032)
    ==00:00:00:20.465 256552==    by 0x2DE3EC: index_create (index.c:1264)
    ==00:00:00:20.465 256552==    by 0x3946F5: DefineIndex (indexcmds.c:1164)
    ==00:00:00:20.465 256552==    by 0x5E6565: ProcessUtilitySlow
    (utility.c:1552)
    ==00:00:00:20.465 256552==    by 0x5E593C: standard_ProcessUtility
    (utility.c:1077)
    ==00:00:00:20.465 256552==    by 0x5E5A01: ProcessUtility (utility.c:530)
    ==00:00:00:20.465 256552==    by 0x5E2DDE: PortalRunUtility
    (pquery.c:1158)
    ==00:00:00:20.465 256552==    by 0x5E30DB: PortalRunMulti (pquery.c:1315)
    ==00:00:00:20.465 256552==    by 0x5E34DD: PortalRun (pquery.c:791)
    ==00:00:00:20.465 256552==  Address 0xeab8f1e is 382 bytes inside a block of
    size 8,192 alloc'd
    ==00:00:00:20.465 256552==    at 0x4848899: malloc (in
    /usr/libexec/valgrind/vgpreload_memcheck-amd64-linux.so)
    ==00:00:00:20.465 256552==    by 0x74FFAD: AllocSetContextCreateInternal
    (aset.c:446)
    ==00:00:00:20.465 256552==    by 0x7383F2: hash_create (dynahash.c:385)
    ==00:00:00:20.465 256552==    by 0x20F852: gistInitBuildBuffers
    (gistbuildbuffers.c:82)
    ==00:00:00:20.465 256552==    by 0x20D5AE: gistInitBuffering
    (gistbuild.c:833)
    ==00:00:00:20.465 256552==    by 0x20EF09: gistBuildCallback
    (gistbuild.c:955)
    ==00:00:00:20.465 256552==    by 0x241838: heapam_index_build_range_scan
    (heapam_handler.c:1794)
    ==00:00:00:20.465 256552==    by 0x20F308: table_index_build_scan
    (tableam.h:1791)
    ==00:00:00:20.465 256552==    by 0x20F308: gistbuild (gistbuild.c:317)
    ==00:00:00:20.465 256552==    by 0x2DC8A9: index_build (index.c:3032)
    ==00:00:00:20.465 256552==    by 0x2DE3EC: index_create (index.c:1264)
    ==00:00:00:20.465 256552==    by 0x3946F5: DefineIndex (indexcmds.c:1164)
    ==00:00:00:20.465 256552==    by 0x5E6565: ProcessUtilitySlow
    (utility.c:1552)
    ==00:00:00:20.465 256552== 
    {
       <insert_a_suppression_name_here>
       Memcheck:Addr2
       fun:gistBuildCallback
       fun:heapam_index_build_range_scan
       fun:table_index_build_scan
       fun:gistbuild
       fun:index_build
       fun:index_create
       fun:DefineIndex
       fun:ProcessUtilitySlow
       fun:standard_ProcessUtility
       fun:ProcessUtility
       fun:PortalRunUtility
       fun:PortalRunMulti
       fun:PortalRun
    }
    ==00:00:00:20.465 256552== 
    ==00:00:00:20.465 256552== Exit program on first error
    (--exit-on-first-error=yes)
    
    This issue reproduces on all supported branches.
    
    
  2. Re: BUG #17874: Incorrect memory access at gistBuildCallback

    Alexander Law <exclusion@gmail.com> — 2023-03-29T10:00:00Z

    Hi Egor,
    
    28.03.2023 19:01, PG Bug reporting form wrote:
    > The following bug has been logged on the website:
    >
    > Bug reference:      17874
    > Logged by:          Egor Chindyaskin
    > Email address:      kyzevan23@mail.ru
    > PostgreSQL version: 15.2
    > Operating system:   Ubuntu 22.04
    > Description:
    >
    > With a server compiled with flag -DUSE_VALGRIND the following query:
    >
    > create table test(a int4, b point);
    >
    > create index test_index on test using gist(b) with (buffering = on,
    > fillfactor=50);
    > drop index test_index;
    > insert into test (a, b) select g, point(g*10, g*10) from generate_series(1,
    > 10000) g;
    > vacuum analyze test;
    >
    > ...
    >
    > causes an incorrect memory access:
    >
    > ==00:00:00:20.465 256552== Invalid read of size 2
    > ==00:00:00:20.465 256552==    at 0x20EE4F: gistBuildCallback
    > (gistbuild.c:921)
    > ...
    >
    > This issue reproduces on all supported branches.
    
    That issue was reported already as bug #16329:
    https://www.postgresql.org/message-id/flat/16329-7a6aa9b6fa1118a1%40postgresql.org
    
    Maybe it's worth to register the fix proposed there for the next commitfest...
    
    Best regards,
    Alexander
    
    
    
    
  3. Re: BUG #17874: Incorrect memory access at gistBuildCallback

    Daniel Gustafsson <daniel@yesql.se> — 2023-03-29T10:11:09Z

    > On 29 Mar 2023, at 12:00, Alexander Lakhin <exclusion@gmail.com> wrote:
    
    > That issue was reported already as bug #16329:
    > https://www.postgresql.org/message-id/flat/16329-7a6aa9b6fa1118a1%40postgresql.org
    > 
    > Maybe it's worth to register the fix proposed there for the next commitfest...
    
    Summarizing that thread and registering the proposed patch for the next
    commitfest seems like the right thing to do.
    
    --
    Daniel Gustafsson
    
    
    
    
    
  4. Re: BUG #17874: Incorrect memory access at gistBuildCallback

    Tom Lane <tgl@sss.pgh.pa.us> — 2023-03-29T11:47:12Z

    Daniel Gustafsson <daniel@yesql.se> writes:
    >> On 29 Mar 2023, at 12:00, Alexander Lakhin <exclusion@gmail.com> wrote:
    >> That issue was reported already as bug #16329:
    >> https://www.postgresql.org/message-id/flat/16329-7a6aa9b6fa1118a1%40postgresql.org
    >> Maybe it's worth to register the fix proposed there for the next commitfest...
    
    > Summarizing that thread and registering the proposed patch for the next
    > commitfest seems like the right thing to do.
    
    Yeah.  We did fix the lack of test coverage that much of that thread
    was about, but it seems like we forgot the original bug (which I
    guess indicates that the coverage is still inadequate, since the
    valgrind buildfarm animals haven't noticed it...)
    
    			regards, tom lane
    
    
    
    
  5. Re: BUG #17874: Incorrect memory access at gistBuildCallback

    Tom Lane <tgl@sss.pgh.pa.us> — 2023-03-29T15:40:47Z

    I wrote:
    > Daniel Gustafsson <daniel@yesql.se> writes:
    >> Summarizing that thread and registering the proposed patch for the next
    >> commitfest seems like the right thing to do.
    
    > Yeah.
    
    I went ahead and reviewed/pushed this, so nevermind about a CF entry.
    
    			regards, tom lane