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 1iK3Jz-0003iH-Nj for pgsql-bugs@arkaria.postgresql.org; Mon, 14 Oct 2019 16:35:48 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1iK3Jy-00073k-DU for pgsql-bugs@arkaria.postgresql.org; Mon, 14 Oct 2019 16:35:46 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1iK3Jy-00073a-0b for pgsql-bugs@lists.postgresql.org; Mon, 14 Oct 2019 16:35:46 +0000 Received: from mail-wr1-x441.google.com ([2a00:1450:4864:20::441]) by magus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1iK3Jv-0001ym-5a for pgsql-bugs@lists.postgresql.org; Mon, 14 Oct 2019 16:35:45 +0000 Received: by mail-wr1-x441.google.com with SMTP id h4so20520180wrv.7 for ; Mon, 14 Oct 2019 09:35:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=2ndquadrant-com.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=WSF6Ij6qgXGjv1Ja675qT1KTYN+LaszR4AzVy6EHVuU=; b=nMvLdCDJwDKeWRb5Sdwg/p5l0iZz0CmlxO1zRxmgmALT5etoLsBAKENVgH09PmfEpZ 2oIJZooq34kEFR5Eb96sWpN/GwNv3UNEpwjpBIMFlA12zcc5OYiZbQXhMMp778Dy18lI PSDiFr32DeAtowM4qyKMJ2E/cyj93GvUFKXTpA0cIhKpWUbfBZiVIBFTGBnrNdzNa1ex lfZ/dwc+FAIalAz5wnXUn94G9kqCZGg2phKgGTHVxKMw9DN1VsFfrOZaApurXGuF6hlZ P3knqu9aR2NAo4+TJL7u8Ljtqnd85b9y1hl5DfRPBcLt5nRu0kXmrTNM6na3jQiH8o7t k5Og== 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:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=WSF6Ij6qgXGjv1Ja675qT1KTYN+LaszR4AzVy6EHVuU=; b=KY290UZqeBMvxno+i0cO9SA9jHDaYlWR30QiaW+b5+CXDjNCKY/cZnubxZllolPLW5 5gn+7drHANCvxwJ2Ph5Ny0H4HQ8ElzGZhVMv0iZesuT22M6s06mEsdYvI1N3/vWVPHAb akyioMuUWfY7d0u/Bn7ca8IQSCrNihkixlkRy1o8K6mJH/Pox7h/gYYB743pVh9c+M5z gvVcmayh9C+5jfihNnXzSDXbBvl0V4LX0d1L3sBLiIoDkbS3oVr3UhBA18d19BW3e/Ay ZjBNYSwEU/NsIa5xwGcap3XSDLeKWK/uSMsV+HKCkvrxzHcfobe5Kf7xCVojlj56zSkb mEMg== X-Gm-Message-State: APjAAAVhmJog9YYRVGz84L+a8tm2MKW4t/9xHa09UrHtOfxb6PERK1zy 2TRCyMAZk3BdQv7TezYnA0ZNIEuyKZe/sggr X-Google-Smtp-Source: APXvYqyTNJ2sn/asM1WFLyFs519U+uN7MTUFa5ToH6EWSeBKtOFN8JvLB5sjpnF3S8mjKNR+QB6QdQ== X-Received: by 2002:a5d:4302:: with SMTP id h2mr17182763wrq.35.1571070941014; Mon, 14 Oct 2019 09:35:41 -0700 (PDT) Received: from localhost (net-188-219-235-30.cust.vodafonedsl.it. [188.219.235.30]) by smtp.gmail.com with ESMTPSA id 90sm28007924wrr.1.2019.10.14.09.35.39 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 14 Oct 2019 09:35:39 -0700 (PDT) Date: Mon, 14 Oct 2019 18:35:38 +0200 From: Tomas Vondra To: Tom Lane Cc: Andres Freund , 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: <20191014163538.cqn6j4cl7s2mk2yz@development> References: <20191010014813.3b2btmkakhrskwgd@alap3.anarazel.de> <20191010134303.bkwjzchjb2w66iro@development> <30706.1570717152@sss.pgh.pa.us> <20191010163350.2rtcjtje6tkgilqi@development> <1542.1570738460@sss.pgh.pa.us> <20191010204022.6hiiubm2cueu3ghk@development> <20191013001032.lqrn4kqaovhrf77l@development> <17717.1570991208@sss.pgh.pa.us> <20191013203848.2eksimmpux3546wr@development> <27596.1571062600@sss.pgh.pa.us> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline In-Reply-To: <27596.1571062600@sss.pgh.pa.us> User-Agent: NeoMutt/20180716 List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk On Mon, Oct 14, 2019 at 10:16:40AM -0400, Tom Lane wrote: >Tomas Vondra writes: >> On Sun, Oct 13, 2019 at 02:26:48PM -0400, Tom Lane wrote: >>> Might be a good idea to exclude attisdropped columns in the part of the >>> recursive query that's looking for sql_identifier columns of composite >>> types. I'm not sure if composites can have dropped columns today, > >[ I checked this, they can ] > >>> but even if they can't it seems like a wise bit of future-proofing. >>> (We'll no doubt have occasion to use this logic again...) > >> Hmm? How could that be safe? Let's say we have a composite type with a >> sql_identifier column, it's used in a table with data, and we drop the >> column. We need the pg_type information to parse the existing, so how >> could we skip attisdropped columns? > >It works exactly like it does for table rowtypes. > >regression=# create type cfoo as (f1 int, f2 int, f3 int); >CREATE TYPE >regression=# alter type cfoo drop attribute f2; >ALTER TYPE >regression=# select attname,atttypid,attisdropped,attlen,attalign from pg_attribute where attrelid = 'cfoo'::regclass; > attname | atttypid | attisdropped | attlen | attalign >------------------------------+----------+--------------+--------+---------- > f1 | 23 | f | 4 | i > ........pg.dropped.2........ | 0 | t | 4 | i > f3 | 23 | f | 4 | i >(3 rows) > >All we need to skip over the dead data is attlen/attalign, which are >preserved in pg_attribute even if the pg_type row is gone. > >As this example shows, you don't really *have* to check attisdropped >because atttypid will be set to zero. But the latter is just a >defense measure in case somebody forgets to check attisdropped; >you're not supposed to forget that. > Aha! I forgot we copy the necessary stuff into pg_attribute. Thanks for clarifying, I'll polish and push the fix shortly. regards -- Tomas Vondra http://www.2ndQuadrant.com PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services