(2009/12/13 11:31), Bruce Momjian wrote:
Bruce Momjian wrote:
KaiGai Kohei wrote:
lo_import() has an another prototype which takes second argument to
specify LOID. Isn't it available to restore a large object with
correct LOID? For example, lo_import('/etc/profile', 1234)
I can't use that because the migration has already brought over the
pg_largeobject file which has the data.
Or, if you intend to restore metadata in the second lo_import(),
ALTER LAEGE OBJECT and GRANT LARGE OBJECT enable to set up metadata
of a certain large object.
Yes, that will work cleanly. The file might be large because I need a
GRANT for every large object, but I suppose that is OK.
Uh, I tested pg_migrator and found a problem with this approach:
test=> select loid from pg_largeobject;
loid
-------
16385
16385
16386
(3 rows)
test=> grant all ON LARGE OBJECT 16385 to public;
ERROR: large object 16385 does not exist
I am wondering if the missing pg_largeobject_metadata row is causing
this, and again I have no way of creating one with the specified oid.
Can SELECT lo_create(16385); help this situation?
It create an entry into pg_largeobject_metadata, but does not touch
pg_largeobject because it is empty in the initial state.
But, in this case, pg_migrator already bring only data chunks to
pg_largeobject. So, this operation enables to recombine orphan chunks
and a metadata entry.
I'm not clear whether we also check pg_largeobejct has chunks with same
LOID on lo_create(). In the regular operation, it shall never happen.
--
KaiGai Kohei <kai...@kaigai.gr.jp>
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
