On Tue, Jan 03, 2017 at 03:35:34PM -0500, Tom Lane wrote:
> Justin Pryzby <pry...@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 |
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
Justin
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
