| From: | Devrim Gündüz <devrim(at)gunduz(dot)org> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | PostgreSQL General <pgsql-general(at)postgresql(dot)org>, Andrew Gierth <andrew(at)tao11(dot)riddles(dot)org(dot)uk> |
| Subject: | Re: Error dumping 9.4: could not parse numeric array |
| Date: | 2017-01-03 15:05:43 |
| Message-ID: | 1483455943.3206.5.camel@gunduz.org |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-general |
Hi Tom,
On Tue, 2017-01-03 at 09:43 -0500, Tom Lane wrote:
> The only conclusion I can draw is that you have a row in pg_proc
> in which proargtypes has more entries than pronargs says there
> should be. How it got that way is not apparent --- but you could
> start by seeing if you can identify the corrupt row(s).
Thank you! I think these lines looks suspicious:
proname | pronargs | proargtypes | probin
---------
---------+----------+-----------------------+--------------
gipr_consistent |
3 | 2281 22793 21 26 2281 | $libdir/ip4r
gip6r_consistent | 3 |
2281 22781 21 26 2281 | $libdir/ip4r
gip4r_consistent | 3 | 2281 22769
21 26 2281 | $libdir/ip4r
They come from ip4r extension, and when I removed them, the error went away.
FWIW, I don't think this is a hardware error, but I'll also put it on the
table. CC'ing Andrew, in case he has some ideas on this.
Regards,
--
Devrim Gündüz
EnterpriseDB: http://www.enterprisedb.com
PostgreSQL Danışmanı/Consultant, Red Hat Certified Engineer
Twitter: @DevrimGunduz , @DevrimGunduzTR
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Ravi Kapoor | 2017-01-03 19:07:27 | questions about 2nd index on one column |
| Previous Message | Tom Lane | 2017-01-03 14:43:28 | Re: Error dumping 9.4: could not parse numeric array |