Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1iICUk-0007w4-Iz for pgsql-bugs@arkaria.postgresql.org; Wed, 09 Oct 2019 13:59:14 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1iICUj-0001og-Ci for pgsql-bugs@arkaria.postgresql.org; Wed, 09 Oct 2019 13:59:13 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1iICUj-0001oT-1x for pgsql-bugs@lists.postgresql.org; Wed, 09 Oct 2019 13:59:13 +0000 Received: from mail-wm1-x344.google.com ([2a00:1450:4864:20::344]) by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1iICUg-0005BH-C7 for pgsql-bugs@lists.postgresql.org; Wed, 09 Oct 2019 13:59:12 +0000 Received: by mail-wm1-x344.google.com with SMTP id y135so4844143wmc.1 for ; Wed, 09 Oct 2019 06:59:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=2ndquadrant-com.20150623.gappssmtp.com; s=20150623; h=date:from:to:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=UCMRqlqbMde+wg7W7TtoA08z22pAiWRPzwyp5S0R550=; b=O+DpEuxD+GPVxwly3do+o82eZWQ4NsMfIKtYCSSWNVmW1kfkEAVwGGLgRYTL4DQT5N c9vQeHzG+SFQGZDaUEowdPX4e8N5bu0co9DlhQX8Wk1Mn8quqtIdk60HX5qUudmFP56r CTXMMXvApr4F1qkaXZCcuAiHaBh9FSwojap5huvWJZM+tiAtVJtgn/W3Y3trlqwJ4Y4H 5P/tCMe5kCN5iwfY24t9QLr3YTPyO5n2B4vArKAdxaqYVAYgtgm8yq/AJOfWaKwMryTL qGU9gJvmY7Bosmnzokt4LBsE4mDbrwe1Trvi6UrtM95x9hpAP3OSqrZYTbOsloNP9UNw r7jg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=UCMRqlqbMde+wg7W7TtoA08z22pAiWRPzwyp5S0R550=; b=sqtlRtE7lssImCxtKqEQCNKwpOzrl5AJ/oZe6jtGp79wyR/GHqhQM2EIj7d5c7gep7 yo8FefKo3VCvE78wvwAQvJ0DVQvZSrDuaSsZ7Pj+30BDdL+8kFHN/c32CJCrnXJRi1jT zvWczs8qJ6bQOjYQhyYGUtpXnouu4cOJGuGOebTtDpqUIIcP8UOFhwlCHZe/bBWNBVWW MBwzeYaiOJ4Jqr4WOxCfHYn6EAwETtypFHk3dZiIzVX9xVVsinSSgq+8m3+xl0rGOof+ rx8tDcOWc62KNYexky4gymr2RxLyJO2Cu9oIgPgsltQT/VXphlMM7BpyEJvh4bbeFiFw tdkA== X-Gm-Message-State: APjAAAVaDmf49YZw87WqHIdHssYZiI5QPVrs/E0za0KC1SxqEgf6a/pn CJLZ8Za3qLxOCXJkRlzyGaoTqw== X-Google-Smtp-Source: APXvYqw4zRYxmPpDs1+rkYUT2rq1rrVhZ6MxpTYZUkJqlqHhhESDPSJwAnSAa2WqqgJNU+hZVfrd0Q== X-Received: by 2002:a1c:dfc4:: with SMTP id w187mr2658648wmg.107.1570629548870; Wed, 09 Oct 2019 06:59:08 -0700 (PDT) Received: from localhost (static-84-42-175-93.net.upcbroadband.cz. [84.42.175.93]) by smtp.gmail.com with ESMTPSA id c17sm3138743wrc.60.2019.10.09.06.59.07 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 09 Oct 2019 06:59:07 -0700 (PDT) Date: Wed, 9 Oct 2019 15:59:07 +0200 From: Tomas Vondra To: buschmann@nidsa.net, pgsql-bugs@lists.postgresql.org Subject: Re: BUG #16045: vacuum_db crash and illegal memory alloc after pg_upgrade from PG11 to PG12 Message-ID: <20191009135907.km2b5nrzflcz6xey@development> References: <16045-673e8fa6b5ace196@postgresql.org> <20191009132436.uugh4r3be6vw6ex4@development> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline In-Reply-To: <20191009132436.uugh4r3be6vw6ex4@development> User-Agent: NeoMutt/20180716 List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk FWIW I can reproduce this - it's enough to do this on the 11 cluster create table q_tbl_archiv as with qseason as ( select table_name,column_name, ordinal_position ,replace(column_name,'_season','') as col_qualifier -- ,'id_'||replace(column_name,'_season','') as id_column from information_schema.columns order by table_name ) select qs.*,c.column_name as id_column, c.column_default as id_default from qseason qs left join information_schema.columns c on c.table_name=qs.table_name and c.column_name like 'id_%'; and then analyze q_tbl_archiv which produces backtrace like this: No symbol "stats" in current context. (gdb) bt #0 0x0000746095262951 in __memmove_avx_unaligned_erms () from /lib64/libc.so.6 #1 0x0000000000890a8e in varstrfastcmp_locale (a1p=0x17716b4 "per_language\a", len1=, a2p=0x176af28 '\177' , "\021\004", len2=-4, ssup=, ssup=) at varlena.c:2320 #2 0x0000000000890cb1 in varlenafastcmp_locale (x=24581808, y=24555300, ssup=0x7ffc649463f0) at varlena.c:2219 #3 0x00000000005b73b4 in ApplySortComparator (ssup=0x7ffc649463f0, isNull2=false, datum2=, isNull1=false, datum1=) at ../../../src/include/utils/sortsupport.h:224 #4 compare_scalars (a=, b=, arg=0x7ffc649463e0) at analyze.c:2700 #5 0x00000000008f9953 in qsort_arg (a=a@entry=0x178fdc0, n=, n@entry=2158, es=es@entry=16, cmp=cmp@entry=0x5b7390 , arg=arg@entry=0x7ffc649463e0) at qsort_arg.c:140 #6 0x00000000005b86a6 in compute_scalar_stats (stats=0x176a208, fetchfunc=, samplerows=, totalrows=2158) at analyze.c:2273 #7 0x00000000005b9d95 in do_analyze_rel (onerel=onerel@entry=0x74608c00d3e8, params=params@entry=0x7ffc64946970, va_cols=va_cols@entry=0x0, acquirefunc=, relpages=22, inh=inh@entry=false, in_outer_xact=false, elevel=13) at analyze.c:529 #8 0x00000000005bb2c9 in analyze_rel (relid=, relation=, params=params@entry=0x7ffc64946970, va_cols=0x0, in_outer_xact=, bstrategy=) at analyze.c:260 #9 0x000000000062c7b0 in vacuum (relations=0x1727120, params=params@entry=0x7ffc64946970, bstrategy=, bstrategy@entry=0x0, isTopLevel=isTopLevel@entry=true) at vacuum.c:413 #10 0x000000000062cd49 in ExecVacuum (pstate=pstate@entry=0x16c9518, vacstmt=vacstmt@entry=0x16a82b8, isTopLevel=isTopLevel@entry=true) at vacuum.c:199 #11 0x00000000007a6d64 in standard_ProcessUtility (pstmt=0x16a8618, queryString=0x16a77a8 "", context=, params=0x0, queryEnv=0x0, dest=0x16a8710, completionTag=0x7ffc64946cb0 "") at utility.c:670 #12 0x00000000007a4006 in PortalRunUtility (portal=0x170f368, pstmt=0x16a8618, isTopLevel=, setHoldSnapshot=, dest=0x16a8710, completionTag=0x7ffc64946cb0 "") at pquery.c:1175 #13 0x00000000007a4b61 in PortalRunMulti (portal=portal@entry=0x170f368, isTopLevel=isTopLevel@entry=true, setHoldSnapshot=setHoldSnapshot@entry=false, dest=dest@entry=0x16a8710, altdest=altdest@entry=0x16a8710, completionTag=completionTag@entry=0x7ffc64946cb0 "") at pquery.c:1321 #14 0x00000000007a5864 in PortalRun (portal=portal@entry=0x170f368, count=count@entry=9223372036854775807, isTopLevel=isTopLevel@entry=true, run_once=run_once@entry=true, dest=dest@entry=0x16a8710, altdest=altdest@entry=0x16a8710, completionTag=0x7ffc64946cb0 "") at pquery.c:796 #15 0x00000000007a174e in exec_simple_query (query_string=0x16a77a8 "") at postgres.c:1215 Looking at compute_scalar_stats, the "stats" parameter does not seem particularly healthy: (gdb) p *stats $3 = {attr = 0x10, attrtypid = 12, attrtypmod = 0, attrtype = 0x1762e00, attrcollid = 356, anl_context = 0x7f7f7f7e00000000, compute_stats = 0x100, minrows = 144, extra_data = 0x1762e00, stats_valid = false, stanullfrac = 0, stawidth = 0, stadistinct = 0, stakind = {0, 0, 0, 0, 0}, staop = {0, 0, 0, 0, 0}, stacoll = {0, 0, 0, 0, 0}, numnumbers = {0, 0, 0, 0, 0}, stanumbers = {0x0, 0x0, 0x0, 0x0, 0x0}, numvalues = {0, 0, 0, 0, 2139062142}, stavalues = { 0x7f7f7f7f7f7f7f7f, 0x7f7f7f7f7f7f7f7f, 0x7f7f7f7f7f7f7f7f, 0x7f7f7f7f7f7f7f7f, 0x7f7f7f7f7f7f7f7f}, statypid = {2139062143, 2139062143, 2139062143, 2139062143, 2139062143}, statyplen = {32639, 32639, 32639, 32639, 32639}, statypbyval = {127, 127, 127, 127, 127}, statypalign = "\177\177\177\177\177", tupattnum = 2139062143, rows = 0x7f7f7f7f7f7f7f7f, tupDesc = 0x7f7f7f7f7f7f7f7f, exprvals = 0x8, exprnulls = 0x4, rowstride = 24522240} Not sure about the root cause yet. regards -- Tomas Vondra http://www.2ndQuadrant.com PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services