Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cOBYE-0007ci-I3 for pgsql-hackers@arkaria.postgresql.org; Mon, 02 Jan 2017 22:57:58 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.84_2) (envelope-from ) id 1cOBYE-0006VC-58 for pgsql-hackers@arkaria.postgresql.org; Mon, 02 Jan 2017 22:57:58 +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_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1cOBWo-0004vJ-1Q for pgsql-hackers@postgresql.org; Mon, 02 Jan 2017 22:56:30 +0000 Received: from mail-it0-x234.google.com ([2607:f8b0:4001:c0b::234]) by magus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.84_2) (envelope-from ) id 1cOBWf-0000iy-B3 for pgsql-hackers@postgresql.org; Mon, 02 Jan 2017 22:56:29 +0000 Received: by mail-it0-x234.google.com with SMTP id o141so263915519itc.0 for ; Mon, 02 Jan 2017 14:56:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telsasoft-com.20150623.gappssmtp.com; s=20150623; h=date:from:to:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=6u55X+/KAyFR0AaK4sxlC4KNffV9h6TvxEz/OAr8nYM=; b=PfYhOBq8QlTvCB4YQZ8+gz4fwfx15Ci1DV6HaTrFld6RO4+Lf1mFZW4yCf4BrILUPU EfDIRvbBMQSwLRa5qqava3cD1eZSRryTWogN9awMN90IlN9Yf3HZrKs/75c6KkrE64Cf tpDYEgUMp5ajOYpiDTJNVhl6xrya8GhCXyAqSGY8x2tMdA7N3tuxh1mgvRvpcCYStodQ wV4a1OuOnhXRnsc+MkIdFrWPF4B5wc6VErSFOQ958HDFWy2DVz0Cczs6hg0le7TJzcB2 GP7r+KwvAn2zaDpUPAg1lUdsEQb3kORvTsXG1kR9cFfbtGj4UXUcGAtBBjdXauzddLnt J1ug== 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=6u55X+/KAyFR0AaK4sxlC4KNffV9h6TvxEz/OAr8nYM=; b=APUMvArOfNQUgOwxpveOeae8qtdp3lHpnLXyRkXdTdSvr+OUTurS/u+0z356HcYNzA XNpIMXqTnn7IvqnyXnHT01wiTmB30jvT7Df+DbZUQ0GNE9xudu5Su+a6TbdahkZdGMs3 BTpwCkw5KCvriaPgExfpo566ouq/OPE5l3HoGvprQZqQToM3IVGn7Ia3B4nh7yOm/fg3 LlmzldGYjiKuFdINVTyBe2vMnOx+Q8CsiA+b4FksKpOvbjVbwuj0Ba/vIyfye36/JPgi lC/92Q50uGYEkoP+U5QCQViPQH82IwTwgKeu6xfPwkn8qOyYc8TX3fCtYa9JZqrvco3R JFUg== X-Gm-Message-State: AIkVDXK8DwNS495rw+dWVVwwCqH12rMFBV4qhUHOlQA33oBaJzCNHE5QMep9rcqHXU0ZYQ== X-Received: by 10.36.35.141 with SMTP id u135mr42952949itu.102.1483397779249; Mon, 02 Jan 2017 14:56:19 -0800 (PST) Received: from pryzbyj (charmander.telsasoft.com. [50.244.222.1]) by smtp.gmail.com with ESMTPSA id 81sm31374060itj.6.2017.01.02.14.56.18 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 02 Jan 2017 14:56:18 -0800 (PST) Received: by pryzbyj (Postfix, from userid 1000) id 2BCD88019CC; Mon, 2 Jan 2017 16:56:18 -0600 (CST) Date: Mon, 2 Jan 2017 16:56:18 -0600 From: Justin Pryzby To: pgsql-hackers@postgresql.org Subject: Re: ALTER TABLE .. ALTER COLUMN .. ERROR: attribute .. has wrong type Message-ID: <20170102225618.GA10071@telsasoft.com> References: <20161012152505.GD12747@telsasoft.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20161012152505.GD12747@telsasoft.com> User-Agent: Mutt/1.5.23 (2014-03-12) X-Pg-Spam-Score: -2.6 (--) List-Archive: List-Help: List-ID: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: X-Mailing-List: pgsql-hackers Precedence: bulk Sender: pgsql-hackers-owner@postgresql.org I originally sent to psql-general some months ago, but it appears it was never delivered (perhaps I wasn't properly subscribed?). Failed to alter table eric_umts_rnc_utrancell_metrics: ERROR: attribute 361 has wrong type DETAIL: Table has type integer, but query expects smallint. We've seen this at least 4 times now, on PG95 and 9.6; 3 of those times are for the above table. Any ideas what I can do to either reproduce it or otherwise avoid it ? On Wed, Oct 12, 2016 at 10:25:05AM -0500, Justin Pryzby wrote: > We've seen this happen at least once on a 9.5 server, and twice on (the same) > server since its upgrade last week to 9.6: > > > ALTER TABLE t ALTER column TYPE says: "ERROR: attribute 81 has wrong type". > > Just now under 9.6 > DETAIL: Table has type integer, but query expects smallint > ... > ts=# SELECT attnum, atttypid, attrelid::regclass FROM pg_attribute WHERE attname='pmnopagingattemptutranrejected' ORDER BY 1 DESC,2,3; > attnum | atttypid | attrelid > --------+----------+--------------------------------- > 193 | 21 | eric_umts_rnc_utrancell_metrics > 193 | 21 | eric_umts_rnc_utrancell_201508 > 179 | 21 | eric_umts_rnc_utrancell_201509 > 179 | 21 | eric_umts_rnc_utrancell_201510 > 179 | 21 | eric_umts_rnc_utrancell_201511 > 179 | 21 | eric_umts_rnc_utrancell_201602 > [...] > 179 | 21 | eric_umts_rnc_utrancell_201610 > 179 | 21 | eric_umts_rnc_utrancell_201611 > (17 rows) > > Last week (same server, same table, still 9.6): > DETAIL: Table has type real, but query expects smallint > > In July (different server) under 9.5 > DETAIL: Table has type real, but query expects smallint > ... > SELECT atttypid, attnum, attrelid::regclass FROM pg_attribute WHERE attname='c_84150886' > atttypid | attnum | attrelid > ----------+--------+----------------------------- > 21 | 200 | huawei_msc_trunkgrp_201605 > 21 | 200 | huawei_msc_trunkgrp_201604 > 21 | 200 | huawei_msc_trunkgrp_201603 > 21 | 200 | huawei_msc_trunkgrp_201602 > 21 | 200 | huawei_msc_trunkgrp_201512 > 21 | 200 | huawei_msc_trunkgrp_201511 > 21 | 200 | huawei_msc_trunkgrp_201510 > 21 | 200 | huawei_msc_trunkgrp_201508 > 21 | 200 | huawei_msc_trunkgrp_201507 > 21 | 200 | huawei_msc_trunkgrp_201506 > 21 | 200 | huawei_msc_trunkgrp_201505 > 21 | 200 | huawei_msc_trunkgrp_201607 > 21 | 200 | huawei_msc_trunkgrp_201606 > 21 | 200 | huawei_msc_trunkgrp_201608 > 21 | 201 | huawei_msc_trunkgrp_metrics > 21 | 200 | huawei_msc_trunkgrp_201509 > 21 | 200 | huawei_msc_trunkgrp_201601 > (17 rows) > > I don't have a clear recollection how I solved this in July; possibly by > restoring the (historic, partition) table from backup. > > Last week again again just now (both under 9.6), a colleague found that he was > able to avoid the error by ALTER TYPE without USING. > > Note that we ALTER TABLE .. NO INHERIT the partitions for all but the most > recent 2 months before ALTERing them (or the parent). The "ALTER NO INHERIT" > and the ALTER TYPE of historic partitions are done outside of a transaction in > order to avoid large additional disk use otherwise used when ALTERing a parent > with many or large children (the sum of the size of the children). -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers