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 1iIbO2-0002oi-Cc for pgsql-bugs@arkaria.postgresql.org; Thu, 10 Oct 2019 16:33:58 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1iIbO1-0004dw-5u for pgsql-bugs@arkaria.postgresql.org; Thu, 10 Oct 2019 16:33:57 +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 1iIbO0-0004dj-Oq for pgsql-bugs@lists.postgresql.org; Thu, 10 Oct 2019 16:33:56 +0000 Received: from mail-wr1-x443.google.com ([2a00:1450:4864:20::443]) by magus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1iIbNx-00028M-Oq for pgsql-bugs@lists.postgresql.org; Thu, 10 Oct 2019 16:33:56 +0000 Received: by mail-wr1-x443.google.com with SMTP id r3so8705202wrj.6 for ; Thu, 10 Oct 2019 09:33:53 -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=nwVnYaEsCkknABFDmPJaVIVywdU97khddQYiwrI+DOM=; b=RmojVcEZBFyi2/5kznpnqM7YKC5RSmy1yJfJPHoARjLB/Hff37lBCeewD87C5BrWs4 RkMP3TcDzkkkEDdufFB+Zwie12ML9gEPJeZZndIjGKivkFifUX860UFjbShvgwloiVKx tIJQdznioOnmrO4EaS8xoL3rTLpXNUTRLozbN4IvI7RX0APCzjisTxlWgcvTJi3HkuMo yAc+/xPAGQrHTIaAKIZKvQFdHb65qKbuncZt36O6SwzMIMp6j43QzmGzuWr3488PODQu Pd1NBKRYJbaevEu1/KWogzn6qNWBxGjwngzqA16NWPsRAaKErQ1iaTUp2S6I21V1RRJI JT5g== 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=nwVnYaEsCkknABFDmPJaVIVywdU97khddQYiwrI+DOM=; b=RoiFrkb36s6rqzCmBVP7DBooIRjZy7W7Y8TFAs3K99FbEXsEzmdvH+OoXAY7Tw5mAK 1ju2XVYk7PVwQchWIPEaHZDC304keGW6i3Zua00Znb4li5594krJhghAYUHhAFTL6+kl qom3lc/0Q4dkNgfRKSKW6aL6/H8fBYA32wr2islnXh+mrcalBcByaOlNIszLkE88lZ7L 9zYk3SUva0GVInxWkzHkjdtcIbp+E2+jjB1LeRBg7tN5ihZ+JIW8BeyeKidSw9u02wdY q7TMM8D8hNn5Hp4OLzAhH0wJiMBC/LL0SlSc0B/sJXlHgqL91HYe1EkLEHhUNrYl8gVD G1nw== X-Gm-Message-State: APjAAAVZ+qmh5YS4gltOn8oXB8bLfZhHXtrBSfjRWUIq23oM1kXwiuhf /4nOjfGpsLPBbKo2kWJfQtvkYku8G24= X-Google-Smtp-Source: APXvYqwCmZVPb3u7A05ctGA5mDwc2f/+ZxXaLiFg0x6VcwgRIHlTGDyVwrQwg0+94z16p8X2fT96xw== X-Received: by 2002:a5d:5743:: with SMTP id q3mr9494479wrw.394.1570725233048; Thu, 10 Oct 2019 09:33:53 -0700 (PDT) Received: from localhost (static-84-42-175-93.net.upcbroadband.cz. [84.42.175.93]) by smtp.gmail.com with ESMTPSA id u6sm7860546wrt.92.2019.10.10.09.33.51 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 10 Oct 2019 09:33:52 -0700 (PDT) Date: Thu, 10 Oct 2019 18:33:50 +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: <20191010163350.2rtcjtje6tkgilqi@development> References: <20191009132436.uugh4r3be6vw6ex4@development> <20191009135907.km2b5nrzflcz6xey@development> <20191009141841.my6k44wfiaquj3ks@development> <20191009230759.ge66neof5qj627a2@development> <19314.1570663125@sss.pgh.pa.us> <20191009232836.jg77wccqwy5fgs6s@development> <20265.1570664514@sss.pgh.pa.us> <20191010014813.3b2btmkakhrskwgd@alap3.anarazel.de> <20191010134303.bkwjzchjb2w66iro@development> <30706.1570717152@sss.pgh.pa.us> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline In-Reply-To: <30706.1570717152@sss.pgh.pa.us> User-Agent: NeoMutt/20180716 List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk On Thu, Oct 10, 2019 at 10:19:12AM -0400, Tom Lane wrote: >Tomas Vondra writes: >> Fair enough, attached is a patch doing that, I think. Maybe the file >> should be named differently, as it contains other objects than just >> tables. > >Seems about right, though I notice it will not detect domains over >sql_identifier. How much do we care about that? > >To identify such domains, I think we'd need something like >WHERE attypid IN (recursive-WITH-query), which makes me nervous. >We did support those starting with 8.4, which is as far back as >pg_upgrade will go, so in theory it should work. But I think we >had bugs with such cases in old releases. Do we want to assume >that the source server has been updated enough to avoid any such >bugs? The expense of such a query might be daunting, too. > Not sure. Regarding bugs, I think it's fine to assume the users are running sufficiently recent version - they may not, but then they're probably subject to various other bugs (data corruption, queries). If they're not, then they'll either get false positives (in which case they'll be forced to update) or false negatives (which is just as if we did nothing). For the query cost, I think we can assume the domain hierarchies are not particularly deep (in practice I'd expect just domains directly on the sql_identifier type). And I doubt people are using that very widely, it's probably more like this report - ad-hoc CTAS, so just a couple of items. So I wouldn't expect it to be a huge deal in most cases. But even if it takes a second or two, it's a one-time cost. regards -- Tomas Vondra http://www.2ndQuadrant.com PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services