While investigating a different issue, I was astonished to find that
pg_restore in HEAD is incapable of restoring dumps containing large
objects: it fails with messages like
pg_restore: [archiver] could not create large object 100000: ERROR: function
call message contains 1 arguments but function requires 2
After some investigation, I find that:
1. Commit c50b7c09d added a function lo_create(oid, bytea).
2. libpq's lo_initialize function, in fe-lobj.c, assumes that
the pg_catalog schema will contain *only one* function named
lo_create (and likewise for lo_open and a dozen other names).
With more than one lo_create function, it's luck of the draw
which one's OID ends up in the PGlobjfuncs struct. If it's
the wrong one, subsequent attempts to use libpq's lo_create()
function fail as above.
While there's certainly a good argument to be made for making
lo_initialize do that query differently, there's no way that we
can fix every copy of libpq that's in the field. I think we have to
consider that "there can be only one lo_create" is effectively part of
the protocol spec for the foreseeable future. (It'd be easy enough
to add a check in the opr_sanity regression test to catch violations
of this rule.)
It's also extremely unfortunate that the regression tests don't
create (or at least don't leave behind) any large objects, as we
might then have possibly caught this bug much earlier.
Meanwhile, we have to either revert the addition of lo_create(oid,
bytea) altogether, or choose a different name for it. Suggestions?
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
