Re: Largeobject Access Controls and pg_migrator

Bruce Momjian <bruce@momjian.us>

From: Bruce Momjian <bruce@momjian.us>
To: KaiGai Kohei <kaigai@kaigai.gr.jp>, KaiGai Kohei <kaigai@ak.jp.nec.com>
Cc: Takahiro Itagaki <itagaki.takahiro@oss.ntt.co.jp>, Tom Lane <tgl@sss.pgh.pa.us>, Jaime Casanova <jcasanov@systemguards.com.ec>, Greg Smith <greg@2ndquadrant.com>, pgsql-hackers@postgresql.org
Date: 2009-12-13T02:31:01Z
Lists: pgsql-hackers
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.

-- 
  Bruce Momjian  <bruce@momjian.us>        http://momjian.us
  EnterpriseDB                             http://enterprisedb.com

  + If your life is a hard drive, Christ can be your backup. +