Re: Largeobject Access Controls (r2460)

From: KaiGai Kohei <kaigai(at)ak(dot)jp(dot)nec(dot)com>
To: Takahiro Itagaki <itagaki(dot)takahiro(at)oss(dot)ntt(dot)co(dot)jp>
Cc: KaiGai Kohei <kaigai(at)kaigai(dot)gr(dot)jp>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Robert Haas <robertmhaas(at)gmail(dot)com>, 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 (r2460)
Date: 2010-02-01 07:10:16
Message-ID: 4B667E58.6030303@ak.jp.nec.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

(2010/02/01 14:19), Takahiro Itagaki wrote:
> As far as I read, the patch is almost ready to commit
> except the following issue about backward compatibility:
>
>> * "BLOB DATA"
>> This section is same as existing "BLOBS" section, except for _LoadBlobs()
>> does not create a new large object before opening it with INV_WRITE, and
>> lo_truncate() will be used instead of lo_unlink() when --clean is given.
>
>> The legacy sections ("BLOBS" and "BLOB COMMENTS") are available to read
>> for compatibility, but newer pg_dump never create these sections.
>
> I wonder we need to support older versions in pg_restore. You add a check
> "PQserverVersion>= 80500" in CleanupBlobIfExists(), but out documentation
> says we cannot use pg_restore 9.0 for 8.4 or older servers:
>
> http://developer.postgresql.org/pgdocs/postgres/app-pgdump.html
> | it is not guaranteed that pg_dump's output can be loaded into
> | a server of an older major version
>
> Can we remove such path and raise an error instead?
> Also, even if we support the older servers in the routine,
> the new bytea format will be another problem anyway.

OK, I'll fix it.

>> One remained issue is the way to decide whether blobs to be dumped, or not.
>> Right now, --schema-only eliminate all the blob dumps.
>> However, I think it should follow the manner in any other object classes.
>>
>> -a, --data-only ... only "BLOB DATA" sections, not "BLOB ITEM"
>> -s, --schema-only ... only "BLOB ITEM" sections, not "BLOB DATA"
>> -b, --blobs ... both of "BLOB ITEM" and "BLOB DATA" independently
>> from --data-only and --schema-only?
>
> I cannot image situations that require data-only dumps -- for example,
> restoring database has a filled pg_largeobject_metadata and an empty
> or broken pg_largeobject -- but it seems to be unnatural.

Indeed, it might not be a sane situation.

However, we can assume the situation that user wants to backup a database
into two separated files (one for schema definition; one for data contents).
Just after restoring schema definitions, all the large obejcts are created
as empty blobs. Then, we can restore their data contents.

I wonder if the behavior is easily understandable for end users.
The "BLOB ITEM" section contains properties of a certain large obejct,
such as identifier (loid), comment, ownership and access privileges.
These are categorized to schema definitions in other object classes,
but we still need special treatment for blobs.

The --schema-only with large objects might be unnatural, but the
--data-only with properties of large objects are also unnatural.
Which behavior is more unnatural?

Thanks,
--
OSS Platform Development Division, NEC
KaiGai Kohei <kaigai(at)ak(dot)jp(dot)nec(dot)com>

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Fujii Masao 2010-02-01 07:39:58 BUG #5304: psql using conninfo fails in connecting to the server
Previous Message Takahiro Itagaki 2010-02-01 05:19:16 Re: Largeobject Access Controls (r2460)