Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1k5CT9-0001q7-G3 for pgsql-bugs@arkaria.postgresql.org; Mon, 10 Aug 2020 18:24:23 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1k5CT8-00012e-4s for pgsql-bugs@arkaria.postgresql.org; Mon, 10 Aug 2020 18:24:22 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1k5CT7-00012X-Q3 for pgsql-bugs@lists.postgresql.org; Mon, 10 Aug 2020 18:24:21 +0000 Received: from mail-qt1-x841.google.com ([2607:f8b0:4864:20::841]) by magus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1k5CT3-0004H1-Lz for pgsql-bugs@lists.postgresql.org; Mon, 10 Aug 2020 18:24:21 +0000 Received: by mail-qt1-x841.google.com with SMTP id o22so7487109qtt.13 for ; Mon, 10 Aug 2020 11:24:17 -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:mime-version:content-disposition :content-transfer-encoding:in-reply-to:user-agent; bh=gcwXyD88pC9ClzYfSouB2mMlikgY9zrlwR6ql9bqKV4=; b=OusZ6ASlElaFalYV27gj50yCRY4/iMOkJqsfzj80Lezu7lI1q5A9z6+d2V4ZRsZDra bCmuBX7CoWRAyO9fRC3MnCU0i0wURx3zqL6sJYBLW4VbJABM5FA5LS4kqMQuU61HD+NO erst0/ecaM1JdWr/W/mgSXitKXLQ76E51Rk3tfCCdIAqYNA/C4a78sCV9GcqBAj/ikTM JoMfefhC852BeRVb+aBz6b0XdlJoESq3CJXNeMCxnXnXRj2WZ41ZufkK28Mb0+SglQzE m6a7E4kG0lo8sYuwKDKXT+m2/wZ7LBpnCpH4RhRUDM57sJxmGsYbkWUtVZfe5mgMnqdP 3Tiw== 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:mime-version :content-disposition:content-transfer-encoding:in-reply-to :user-agent; bh=gcwXyD88pC9ClzYfSouB2mMlikgY9zrlwR6ql9bqKV4=; b=pKcbg/QGutrW7wZyGxe4CP0gjDuaFosklPKyKgSv1fhXvN47bohnS0rIt9AtVDS7/E mGFJ65BwveWMydYHtF2X77zqlOelVUDR3E0R97mzG02HIivGFDJDCR/tkTECuN7UPWzW CeIEDSlfN0S+Y+7dBQ2qA5yOdbY//SmWYghmpl08Jd7XQIijKTwrBQJFSCz+jGlShI1U 0wwuH8Yf/ZObaTM3EhA/7iX7Hi8G3+puzEvrevr1U4JDKirnITu71KW8gnyDKAq1g+3l PeqHJqV8MHJMn7v7JHJKiMadlvQEMUDBB6inYOeB2fkXUu2rECzhMvoRxNM/sNcBjMDG mYSg== X-Gm-Message-State: AOAM530ZUHruZZtriFDgxUnM5Q0bhzX8S9OFyiXatncm+4RAjb9nF8d3 umBjg43kZ0ZSUVLvKY//Z89GdQ== X-Google-Smtp-Source: ABdhPJzlRGQvJeyF53rm25UzSXdiYXT0c/hsXI3tZga0am9BeozC5jWD5Y90dlk6SU6lGXUO7aif1A== X-Received: by 2002:ac8:2ab9:: with SMTP id b54mr3435768qta.323.1597083855693; Mon, 10 Aug 2020 11:24:15 -0700 (PDT) Received: from perhan.alvh.no-ip.org ([190.95.19.47]) by smtp.gmail.com with ESMTPSA id k31sm16370622qtd.60.2020.08.10.11.24.14 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 10 Aug 2020 11:24:14 -0700 (PDT) Received: by perhan.alvh.no-ip.org (Postfix, from userid 1000) id E878D2A1527; Mon, 10 Aug 2020 14:24:12 -0400 (-04) Date: Mon, 10 Aug 2020 14:24:12 -0400 From: Alvaro Herrera To: Tom Lane Cc: Michael Paquier , exclusion@gmail.com, pgsql-bugs@lists.postgresql.org Subject: Re: BUG #16577: Segfault on altering a table located in a dropped tablespace Message-ID: <20200810182412.GA19588@alvherre.pgsql> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="J2SCkAp4GZ/dPZZf" Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <3064988.1596991985@sss.pgh.pa.us> User-Agent: Mutt/1.10.1 (2018-07-13) List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk --J2SCkAp4GZ/dPZZf Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit On 2020-Aug-09, Tom Lane wrote: > Michael Paquier writes: > > Thanks Alexander for the report. Interesting case indeed. > > For a normal table we would complain that the tablespace is not empty > > when attempting to drop the tablespace. But here we have only one > > partitioned table still holding references to the tablespace. Ah, so it turns out that the physical files were necessary after all. Maybe the solution to this problem is indeed to have them. It means partly reverting this commit: commit 807ae415c54628ade937cb209f0fc9913e6b0cf5 Author: Alvaro Herrera AuthorDate: Fri Jan 4 14:51:17 2019 -0300 CommitDate: Fri Jan 4 14:51:17 2019 -0300 Don't create relfilenode for relations without storage Some relation kinds had relfilenode set to some non-zero value, but apparently the actual files did not really exist because creation was prevented elsewhere. Get rid of the phony pg_class.relfilenode values. Catversion bumped, but only because the sanity_test check will fail if run in a system initdb'd with the previous version. Reviewed-by: Kyotaro HORIGUCHI, Michael Paquier Discussion: https://postgr.es/m/20181206215552.fm2ypuxq6nhpwjuc@alvherre.pgsql But also fixing whatever *other* code was preventing creating of the filenodes. As for the crash at hand, it seems it can be solved easily by making ruleutils avoid trying to dereference a null pointer, as in the attached patch. This seems necessary for branches 12 and 13, which have the above commit, but not for 10/11 (which do have relfilenodes) nor master, where we can revert it. -- Álvaro Herrera https://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services --J2SCkAp4GZ/dPZZf Content-Type: text/x-diff; charset=us-ascii Content-Disposition: attachment; filename="part-idx-tblspc.patch" diff --git a/src/backend/utils/adt/ruleutils.c b/src/backend/utils/adt/ruleutils.c index 2cbcb4b85e..d6c4b5eb0c 100644 --- a/src/backend/utils/adt/ruleutils.c +++ b/src/backend/utils/adt/ruleutils.c @@ -1451,14 +1451,24 @@ pg_get_indexdef_worker(Oid indexrelid, int colno, if (showTblSpc) { Oid tblspc; + char *spcname = NULL; + /* + * If this is an index on a partitioned table, it's possible that + * the tablespace was dropped, because there are insufficient + * protections in that case. Don't add anything if so (and also + * don't crash). + */ tblspc = get_rel_tablespace(indexrelid); - if (OidIsValid(tblspc)) + if (tblspc != InvalidOid) + spcname = get_tablespace_name(tblspc); + if (spcname != NULL) { if (isConstraint) appendStringInfoString(&buf, " USING INDEX"); appendStringInfo(&buf, " TABLESPACE %s", - quote_identifier(get_tablespace_name(tblspc))); + quote_identifier(spcname)); + pfree(spcname); } } @@ -2188,6 +2198,7 @@ pg_get_constraintdef_worker(Oid constraintId, bool fullCommand, { char *options = flatten_reloptions(indexId); Oid tblspc; + char *spcname = NULL; if (options) { @@ -2200,11 +2211,18 @@ pg_get_constraintdef_worker(Oid constraintId, bool fullCommand, * This is to help ALTER TABLE usage of this facility, * which needs this behavior to recreate exact catalog * state. + * + * If this is an index on a partitioned table, it's + * possible that the tablespace was dropped, because there + * are insufficient protections in that case. Don't add + * anything if so (and also don't crash). */ tblspc = get_rel_tablespace(indexId); - if (OidIsValid(tblspc)) + if (tblspc != InvalidOid) + spcname = get_tablespace_name(tblspc); + if (spcname != NULL) appendStringInfo(&buf, " USING INDEX TABLESPACE %s", - quote_identifier(get_tablespace_name(tblspc))); + quote_identifier(spcname)); } break; --J2SCkAp4GZ/dPZZf--