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 1iIYip-000510-7e for pgsql-bugs@arkaria.postgresql.org; Thu, 10 Oct 2019 13:43:15 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1iIYin-0003M3-SR for pgsql-bugs@arkaria.postgresql.org; Thu, 10 Oct 2019 13:43:13 +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 1iIYin-0003Lr-JR for pgsql-bugs@lists.postgresql.org; Thu, 10 Oct 2019 13:43:13 +0000 Received: from mail-wr1-x444.google.com ([2a00:1450:4864:20::444]) by magus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1iIYik-0000TS-68 for pgsql-bugs@lists.postgresql.org; Thu, 10 Oct 2019 13:43:12 +0000 Received: by mail-wr1-x444.google.com with SMTP id r5so7934240wrm.12 for ; Thu, 10 Oct 2019 06:43:09 -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=541HAklBgkQmYeGCDTYBO6aGI/IxWNBdBW5kkf5Yuv0=; b=Ii1dvEVBMpD3mz1xoZOqreubGiU3NkySx+RNyKfFWz6jwXVVoMdkhb1AI5gvCYWnYe xqy6LdVgAVdP1P9Z2/cEyeXspMk41t9QwoSpDvNreXe1THk2bON2Yyr/tN3n3iFbAzv9 /5PzHMcQN5dQKbhgKUKlmulWyFkrxUBMUOd+7PbVoYXXMp1iIrgia0cblk6RpvKkdVVX JoJg0BtvoZcm+scpMkv6AKXwXpHmFQx8DZk1+ItlnbPMriKWRV+mZ8WqyPDGYygbJyp1 XvuyT64fsd1N4PH8u06Q1vQ2pLHG4OeVVWUaO1QbdVMywUAygjOGDp6rJxMWGVYMWgrb 0N8g== 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=541HAklBgkQmYeGCDTYBO6aGI/IxWNBdBW5kkf5Yuv0=; b=KxEqusDus77e8KYz5lyKJyKHrTc2HuqCkyHopAqf/Eg+La8RxBlVVy/9D0qk4H5Pkg c0BM5oT3F9ahwq8veHCQ5Swlvlc0PYZyuIIlaLu0AjKO+dbBKC3CqU8J/au+V8ylhinm Pdmkb8fQrwPCz6cCfQlmmaoGL/Ik28IEXPIyb/vGpZdTMxntIM1K6KyI7J0sP3hlRwCH Bxg5xsvpwg28r8ccOVJOFNulDAHCVx7+q01wwuwzk3iBQnsZwskkprtjQqAXqYv1DEDf LlERkwj62UzXFq3shg2DoU8mnbz9aAOYh9pA6qbANA8nrq9wvbl4qtHpiOYW8SW0fLn7 hp9g== X-Gm-Message-State: APjAAAUpoTX0fZsGTxtZ58rLw55sTzg0FDoy9PQG3rGgGvtrLfCDtSzT keMzA+rEgxl6PW7YmGMbVoD+SIPpxKY= X-Google-Smtp-Source: APXvYqyJEG+5orSeKv9QQR/Go6GkST3iwp96rUNPrSZv8IfDnMGEV6Zcp2oTst5EnW2sotoexObb5w== X-Received: by 2002:a5d:6383:: with SMTP id p3mr8699650wru.117.1570714989100; Thu, 10 Oct 2019 06:43:09 -0700 (PDT) Received: from localhost (static-84-42-175-93.net.upcbroadband.cz. [84.42.175.93]) by smtp.gmail.com with ESMTPSA id f9sm8735169wre.74.2019.10.10.06.43.04 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 10 Oct 2019 06:43:04 -0700 (PDT) Date: Thu, 10 Oct 2019 15:43:03 +0200 From: Tomas Vondra To: Andres Freund Cc: Tom Lane , 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: <20191010134303.bkwjzchjb2w66iro@development> References: <16045-673e8fa6b5ace196@postgresql.org> <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> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="to4lpegnfgybv64f" Content-Disposition: inline In-Reply-To: <20191010014813.3b2btmkakhrskwgd@alap3.anarazel.de> User-Agent: NeoMutt/20180716 List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk --to4lpegnfgybv64f Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline On Wed, Oct 09, 2019 at 06:48:13PM -0700, Andres Freund wrote: >On 2019-10-09 19:41:54 -0400, Tom Lane wrote: >> Also, even if we did try to silently convert such columns that way, >> I bet we'd get other bug reports about "why'd my columns suddenly >> change type?". So I'd rather force the user to be involved. > >+1 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. regards -- Tomas Vondra http://www.2ndQuadrant.com PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services --to4lpegnfgybv64f Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="pg-upgrade-sql-identifier-fix.patch" diff --git a/src/bin/pg_upgrade/check.c b/src/bin/pg_upgrade/check.c index 617270f101..c6dc50f3e6 100644 --- a/src/bin/pg_upgrade/check.c +++ b/src/bin/pg_upgrade/check.c @@ -108,6 +108,13 @@ check_and_dump_old_cluster(bool live_check) if (GET_MAJOR_VERSION(old_cluster.major_version) <= 1100) check_for_tables_with_oids(&old_cluster); + /* + * PG 12 changed the 'sql_identifier' type storage format, so we need + * to prevent upgrade when used in user objects (tables, indexes, ...) + */ + if (GET_MAJOR_VERSION(old_cluster.major_version) <= 1100) + old_11_check_for_sql_identifier_data_type_usage(&old_cluster); + /* * Pre-PG 10 allowed tables with 'unknown' type columns and non WAL logged * hash indexes diff --git a/src/bin/pg_upgrade/pg_upgrade.h b/src/bin/pg_upgrade/pg_upgrade.h index 5d31750d86..63574b51bc 100644 --- a/src/bin/pg_upgrade/pg_upgrade.h +++ b/src/bin/pg_upgrade/pg_upgrade.h @@ -458,6 +458,8 @@ void old_9_6_check_for_unknown_data_type_usage(ClusterInfo *cluster); void old_9_6_invalidate_hash_indexes(ClusterInfo *cluster, bool check_mode); +void old_11_check_for_sql_identifier_data_type_usage(ClusterInfo *cluster); + /* parallel.c */ void parallel_exec_prog(const char *log_file, const char *opt_log_file, const char *fmt,...) pg_attribute_printf(3, 4); diff --git a/src/bin/pg_upgrade/version.c b/src/bin/pg_upgrade/version.c index 10cb362e09..8d766d3d3a 100644 --- a/src/bin/pg_upgrade/version.c +++ b/src/bin/pg_upgrade/version.c @@ -399,3 +399,101 @@ old_9_6_invalidate_hash_indexes(ClusterInfo *cluster, bool check_mode) else check_ok(); } + +/* + * old_11_check_for_sql_identifier_data_type_usage() + * 11 -> 12 + * In 12, the sql_identifier data type was switched from name to varchar, + * which does affect the storage (name is by-ref, but not varlena). This + * means user tables using sql_identifier for columns are broken because + * the on-disk format is different. + * + * We need to check all objects that might store sql_identifier on disk, + * i.e. tables, matviews and indexes. Also check composite types in case + * they are used in this context. + */ +void +old_11_check_for_sql_identifier_data_type_usage(ClusterInfo *cluster) +{ + int dbnum; + FILE *script = NULL; + bool found = false; + char output_path[MAXPGPATH]; + + prep_status("Checking for invalid \"sql_identifier\" user columns"); + + snprintf(output_path, sizeof(output_path), "tables_using_sql_identifier.txt"); + + for (dbnum = 0; dbnum < cluster->dbarr.ndbs; dbnum++) + { + PGresult *res; + bool db_used = false; + int ntups; + int rowno; + int i_nspname, + i_relname, + i_attname; + DbInfo *active_db = &cluster->dbarr.dbs[dbnum]; + PGconn *conn = connectToServer(cluster, active_db->db_name); + + res = executeQueryOrDie(conn, + "SELECT n.nspname, c.relname, a.attname " + "FROM pg_catalog.pg_class c, " + " pg_catalog.pg_namespace n, " + " pg_catalog.pg_attribute a " + "WHERE c.oid = a.attrelid AND " + " NOT a.attisdropped AND " + " a.atttypid = 'information_schema.sql_identifier'::pg_catalog.regtype AND " + " c.relkind IN (" + CppAsString2(RELKIND_RELATION) ", " + CppAsString2(RELKIND_COMPOSITE_TYPE) ", " + CppAsString2(RELKIND_MATVIEW) ", " + CppAsString2(RELKIND_INDEX) ") AND " + " c.relnamespace = n.oid AND " + /* exclude possible orphaned temp tables */ + " n.nspname !~ '^pg_temp_' AND " + " n.nspname !~ '^pg_toast_temp_' AND " + " n.nspname NOT IN ('pg_catalog', 'information_schema')"); + + ntups = PQntuples(res); + i_nspname = PQfnumber(res, "nspname"); + i_relname = PQfnumber(res, "relname"); + i_attname = PQfnumber(res, "attname"); + for (rowno = 0; rowno < ntups; rowno++) + { + found = true; + if (script == NULL && (script = fopen_priv(output_path, "w")) == NULL) + pg_fatal("could not open file \"%s\": %s\n", output_path, + strerror(errno)); + if (!db_used) + { + fprintf(script, "Database: %s\n", active_db->db_name); + db_used = true; + } + fprintf(script, " %s.%s.%s\n", + PQgetvalue(res, rowno, i_nspname), + PQgetvalue(res, rowno, i_relname), + PQgetvalue(res, rowno, i_attname)); + } + + PQclear(res); + + PQfinish(conn); + } + + if (script) + fclose(script); + + if (found) + { + pg_log(PG_REPORT, "fatal\n"); + pg_fatal("Your installation contains the \"sql_identifier\" data type in user tables\n" + "and/or indexes. The on-disk format for this data type has changed, so this\n" + "cluster cannot currently be upgraded. You can remove the problem tables or\n" + "change the data type to \"name\" and restart the upgrade.\n" + "A list of the problem columns is in the file:\n" + " %s\n\n", output_path); + } + else + check_ok(); +} --to4lpegnfgybv64f--