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