That post was made more than 10 years ago, but I figured it was worth a try, and set my pg_dump to run with PGOPTIONS="-d2". Sure enough, the crash is preceded by the following lines:
SELECT proretset, prosrc, probin, proallargtypes, proargmodes, proargnames, provolatile, proisstrict, prosecdef, proconfig, procost, prorows, (SELECT lanname FROM pg_catalog.pg_language WHERE oid = prolang) as lanname FROM pg_catalog.pg_proc WHERE oid = '16730'::pg_catalog.oid
SELECT pg_catalog.format_type('1185'::pg_catalog.oid, NULL)
SELECT pg_catalog.format_type('1022'::pg_catalog.oid, NULL)
SELECT pg_catalog.format_type('1184'::pg_catalog.oid, NULL)
SELECT pg_catalog.format_type('701'::pg_catalog.oid, NULL)
SELECT pg_catalog.format_type('1185'::pg_catalog.oid, NULL)
SELECT pg_catalog.format_type('1022'::pg_catalog.oid, NULL)
SELECT pg_catalog.format_type('2249'::pg_catalog.oid, NULL)
The OIDs 1185, 1022, 1184 and 701 are present in proallargtypes, so pg_dump appears to be looking up argument types for that function. I couldn't see 2249 anywhere, though, so I ran this:
SELECT * FROM pg_catalog.pg_proc WHERE oid = '16730'
And 2249 showed up in prorettype. The result from that last query is 'record', since the function RETURNS SETOF RECORD.
That original post turned out to be some temporary trigger function that the user simply deleted to solve the problem. This function, however, is legitimate, and I can't simply delete it. Does anyone know what might be happening here, and how to work around it? Thanks!