Justin Pryzby <pry...@telsasoft.com> writes:
> On Tue, Jan 03, 2017 at 03:35:34PM -0500, Tom Lane wrote:
>> 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 |
> 21
> eric_umts_rnc_utrancell_metrics | pmsumpacketlatency_000 | 424 |
> 23
> eric_umts_rnc_utrancell_201701 | pmsumpacketlatency_000 | 367 |
> 23
> eric_umts_rnc_utrancell_201701 | pmulupswitchsuccessmedium | 424 |
> 21
Yup. So if you can't wait for a fix, your best bet would be to dump and
reload these tables, which should bring their attnums back in sync.
(Of course, they might not stay that way for long, if you're also
in the habit of adding columns often.)
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
