(2009/12/13 10:39), Bruce Momjian wrote:
Bruce Momjian wrote:
KaiGai Kohei wrote:
What happens when
there is no entry in pg_largeobject_metadata for a specific row?
In this case, these rows become orphan.
So, I think we need to create an empty large object with same LOID on
pg_migrator. It makes an entry on pg_largeobject_metadata without
writing anything to the pg_largeobject.
I guess rest of migrations are not difference. Correct?
Agreed. I have modified pg_migrator with the attached patch which
creates a script that adds default permissions for all large object
tables.
Oops, seem like I have a problem in getting pg_migrator to populate
pg_largeobject_metadata:
test=> select lo_import('/etc/profile');
lo_import
-----------
16385
(1 row)
test=> select lo_import('/etc/profile.env');
lo_import
-----------
16386
(1 row)
test=> select oid,* from pg_largeobject_metadata;
oid | lomowner | lomacl
-------+----------+--------
16385 | 10 |
16386 | 10 |
(2 rows)
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)
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.
Or, am I missing the problem?
You might remember that INSERT cannot set the oid of a row, so I don't
see how pg_migrator can migrate this? Is there a reason we used 'oid'
in pg_largeobject_metadata but 'lobj' in pg_largeobject? Why did't we
add the lomowner and lomacl columns to pg_largeobject?
A large object consists of multiple tuples within pg_largeobject.
If we added lomowner and lomacl into pg_largeobject, we have to manage
all the pages in a large object to keep consistent state.
--
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
