Re: Largeobject Access Controls (r2460) - Mailing list pgsql-hackers

From KaiGai Kohei
Subject Re: Largeobject Access Controls (r2460)
Date
Msg-id 4B21F8CE.108@ak.jp.nec.com
Whole thread Raw
In response to Re: Largeobject Access Controls (r2460)  (Takahiro Itagaki <itagaki.takahiro@oss.ntt.co.jp>)
Responses Re: Largeobject Access Controls (r2460)
List pgsql-hackers
Takahiro Itagaki wrote:
> KaiGai Kohei <kaigai@ak.jp.nec.com> wrote:
> 
>> The attached patch fixes these matters.
> 
> I'll start to check it.

Thanks,

>>   We have to reference pg_largeobject_metadata to check whether a certain
>>   large objct exists, or not.
> 
> What is the situation where there is a row in pg_largeobject_metadata
> and no corresponding rows in pg_largeobject? Do we have a method to
> delete all rows in pg_largeobject but leave some metadata?

It is a case when we create a new large object, but write nothing.
 postgres=# SELECT lo_create(1234);  lo_create -----------       1234 (1 row)
 postgres=# SELECT * FROM pg_largeobject_metadata WHERE oid = 1234;  lomowner | lomacl ----------+--------        10 |
(1row)
 
 postgres=# SELECT * FROM pg_largeobject WHERE loid = 1234;  loid | pageno | data ------+--------+------ (0 rows)

In this case, the following two queries are not equivalent.* SELECT oid FROM pg_largeobject_metadata* SELECT DISTINCT
loidFROM pg_largeobject
 

The second query does not return the loid of empty large objects.

The prior implementation inserted a zero-length page to show here is
a large object with this loid, but it got unnecessary with this
enhancement.
If we need compatibility in this level, we can insert a zero-length
page into pg_largeobject on LargeObjectCreate().
It is harmless, but its worth is uncertain.

Thanks,
-- 
OSS Platform Development Division, NEC
KaiGai Kohei <kaigai@ak.jp.nec.com>


pgsql-hackers by date:

Previous
From: Takahiro Itagaki
Date:
Subject: Re: Largeobject Access Controls (r2460)
Next
From: Fujii Masao
Date:
Subject: Re: Streaming replication, some small issues