Re: [HACKERS] ALTER TABLE .. ALTER COLUMN .. ERROR: attribute .. haswrong type

On Tue, Jan 03, 2017 at 03:35:34PM -0500, Tom Lane wrote:
> Justin Pryzby <pryzby@telsasoft.com> writes:
> > On Tue, Jan 03, 2017 at 03:18:15PM -0500, Tom Lane wrote:
> >> I'm wondering if this represents some sort of out-of-sync condition
> >> between the table and its child tables.  We can't actually tell from
> >> this trace which table is being processed.  Could you try, from this
> >> breakpoint,
> >> 
> >> f 3
> >> p oldrel->rd_rel->relname
> 
> > (gdb) p oldrel->rd_rel->relname
> > $1 = {data = "eric_umts_rnc_utrancell_201701", '\000' <repeats 33 times>}
> 
> Right.  So I bet that if you check the attnum of pmsumpacketlatency_000 in
> eric_umts_rnc_utrancell_metrics, you'll find it's different from that in
> eric_umts_rnc_utrancell_201701, and that the attribute having that attnum
> in eric_umts_rnc_utrancell_201701 has type smallint not int.

I think that's consistent with what your understanding:

ts=# SELECT attrelid::regclass, attname, attnum, atttypid FROM pg_attribute WHERE
attrelid::regclass::text~'eric_umts_rnc_utrancell_(metrics|201701)$'AND (attname='pmsumpacketlatency_000' OR attnum IN
(367,424)) ORDER BY 1,2;eric_umts_rnc_utrancell_metrics | pmsamplespshsadchrabestablish |    367 |
21eric_umts_rnc_utrancell_metrics| pmsumpacketlatency_000        |    424 |       23eric_umts_rnc_utrancell_201701  |
pmsumpacketlatency_000       |    367 |       23eric_umts_rnc_utrancell_201701  | pmulupswitchsuccessmedium     |
424|       21
 

Justin