Skip site navigation (1) Skip section navigation (2)

Re: Largeobject Access Controls and pg_migrator

From: KaiGai Kohei <kaigai(at)kaigai(dot)gr(dot)jp>
To: Bruce Momjian <bruce(at)momjian(dot)us>
Cc: KaiGai Kohei <kaigai(at)ak(dot)jp(dot)nec(dot)com>, Takahiro Itagaki <itagaki(dot)takahiro(at)oss(dot)ntt(dot)co(dot)jp>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Jaime Casanova <jcasanov(at)systemguards(dot)com(dot)ec>, Greg Smith <greg(at)2ndquadrant(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Largeobject Access Controls and pg_migrator
Date: 2009-12-13 03:48:11
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
(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 <kaigai(at)kaigai(dot)gr(dot)jp>

In response to


pgsql-hackers by date

Next:From: Robert HaasDate: 2009-12-13 03:56:42
Subject: Re: 8.4.1 ubuntu karmic slow createdb
Previous:From: Robert HaasDate: 2009-12-13 03:18:46
Subject: Re: Row-Level Security

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group