Andres Freund just forwarded me a valgrind error report that Peter Geoghegan noticed:
==29892== Unaddressable byte(s) found during client check request ==29892== at 0x7D1317: PageAddItem (bufpage.c:314) ==29892== by 0x468106: brin_doinsert (brin_pageops.c:315) ==29892== by 0x4671A5: form_and_insert_tuple (brin.c:1178) ==29892== by 0x466006: brinbuildCallback (brin.c:596) ==29892== by 0x53F6E4: IndexBuildHeapRangeScan (index.c:2548) ==29892== by 0x53EC19: IndexBuildHeapScan (index.c:2161) ==29892== by 0x466443: brinbuild (brin.c:694) ==29892== by 0x92F09F: OidFunctionCall3Coll (fmgr.c:1649) ==29892== by 0x53E924: index_build (index.c:2024) ==29892== by 0x53D5FC: index_create (index.c:1099) ==29892== by 0x60B3B7: DefineIndex (indexcmds.c:605) ==29892== by 0x7E2142: ProcessUtilitySlow (utility.c:1203) ==29892== Address 0xccffd86 is 5,270 bytes inside a block of size 8,192 alloc'd ==29892== at 0x4C2AB80: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) ==29892== by 0x950425: AllocSetAlloc (aset.c:847) ==29892== by 0x9530A5: palloc (mcxt.c:821) ==29892== by 0x4C6A32: heap_tuple_untoast_attr (tuptoaster.c:215) ==29892== by 0x9302F2: pg_detoast_datum (fmgr.c:2238) ==29892== by 0x8794C8: numeric_lt (numeric.c:2060) ==29892== by 0x92E211: FunctionCall2Coll (fmgr.c:1323) ==29892== by 0x46C441: brin_minmax_add_value (brin_minmax.c:113) ==29892== by 0x92E49C: FunctionCall4Coll (fmgr.c:1375) ==29892== by 0x466108: brinbuildCallback (brin.c:618) ==29892== by 0x53F6E4: IndexBuildHeapRangeScan (index.c:2548) ==29892== by 0x53EC19: IndexBuildHeapScan (index.c:2161) What I think this means is that during an index build brin_minmax_add_value() called numeric_lt() which detoasted one of its input values; later, brin_doinsert() inserts a tuple containing the value, but it tries to use more bytes than were allocated. I haven't had time to actually study what is going on here, but wanted to archive this publicly. (Value detoasting evidently plays a role here, but I don't know how.) -- Álvaro Herrera http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
