Re: [PoC] Improve dead tuple storage for lazy vacuum - Mailing list pgsql-hackers

From Andres Freund
Subject Re: [PoC] Improve dead tuple storage for lazy vacuum
Date
Msg-id 20221122171000.rp3zwxpzg7whv7pa@awork3.anarazel.de
Whole thread Raw
In response to Re: [PoC] Improve dead tuple storage for lazy vacuum  (Masahiko Sawada <sawada.mshk@gmail.com>)
Responses Re: [PoC] Improve dead tuple storage for lazy vacuum
List pgsql-hackers
On 2022-11-21 17:06:56 +0900, Masahiko Sawada wrote:
> Sure. I've attached the v10 patches. 0004 is the pure refactoring
> patch and 0005 patch introduces the pointer tagging.

This failed on cfbot, with som many crashes that the VM ran out of disk for
core dumps. During testing with 32bit, so there's probably something broken
around that.

https://cirrus-ci.com/task/4635135954386944

A failure is e.g. at:
https://api.cirrus-ci.com/v1/artifact/task/4635135954386944/testrun/build-32/testrun/adminpack/regress/log/initdb.log

performing post-bootstrap initialization ... ../src/backend/lib/radixtree.c:1696:21: runtime error: member access
withinmisaligned address 0x590faf74 for type 'struct radix_tree_control', which requires 8 byte alignment
 
0x590faf74: note: pointer points here
  90 11 00 00 00 00 00 00  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00
              ^
==55813==Using libbacktrace symbolizer.
    #0 0x56dcc274 in rt_create ../src/backend/lib/radixtree.c:1696
    #1 0x56953d1b in tidstore_create ../src/backend/access/common/tidstore.c:57
    #2 0x56a1ca4f in dead_items_alloc ../src/backend/access/heap/vacuumlazy.c:3109
    #3 0x56a2219f in heap_vacuum_rel ../src/backend/access/heap/vacuumlazy.c:539
    #4 0x56cb77ed in table_relation_vacuum ../src/include/access/tableam.h:1681
    #5 0x56cb77ed in vacuum_rel ../src/backend/commands/vacuum.c:2062
    #6 0x56cb9a16 in vacuum ../src/backend/commands/vacuum.c:472
    #7 0x56cba904 in ExecVacuum ../src/backend/commands/vacuum.c:272
    #8 0x5711b6d0 in standard_ProcessUtility ../src/backend/tcop/utility.c:866
    #9 0x5711bdeb in ProcessUtility ../src/backend/tcop/utility.c:530
    #10 0x5711759f in PortalRunUtility ../src/backend/tcop/pquery.c:1158
    #11 0x57117cb8 in PortalRunMulti ../src/backend/tcop/pquery.c:1315
    #12 0x571183d2 in PortalRun ../src/backend/tcop/pquery.c:791
    #13 0x57111049 in exec_simple_query ../src/backend/tcop/postgres.c:1238
    #14 0x57113f9c in PostgresMain ../src/backend/tcop/postgres.c:4551
    #15 0x5711463d in PostgresSingleUserMain ../src/backend/tcop/postgres.c:4028
    #16 0x56df4672 in main ../src/backend/main/main.c:197
    #17 0xf6ad8e45 in __libc_start_main (/lib/i386-linux-gnu/libc.so.6+0x1ae45)
    #18 0x5691d0f0 in _start (/tmp/cirrus-ci-build/build-32/tmp_install/usr/local/pgsql/bin/postgres+0x3040f0)

Aborted (core dumped)
child process exited with exit code 134
initdb: data directory "/tmp/cirrus-ci-build/build-32/testrun/adminpack/regress/tmp_check/data" not removed at user's
request



pgsql-hackers by date:

Previous
From: Simon Riggs
Date:
Subject: Re: Slow standby snapshot
Next
From: Andres Freund
Date:
Subject: Re: Postgres picks suboptimal index after building of an extended statistics