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

Re: Largeobject Access Controls (r2460)

From: KaiGai Kohei <kaigai(at)kaigai(dot)gr(dot)jp>
To: Takahiro Itagaki <itagaki(dot)takahiro(at)oss(dot)ntt(dot)co(dot)jp>
Cc: KaiGai Kohei <kaigai(at)ak(dot)jp(dot)nec(dot)com>, Alvaro Herrera <alvherre(at)commandprompt(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, 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 (r2460)
Date: 2010-02-09 12:18:22
Message-ID: 4B71528E.5080301@kaigai.gr.jp (view raw or flat)
Thread:
Lists: pgsql-hackers
(2010/02/09 20:16), Takahiro Itagaki wrote:
>
> KaiGai Kohei<kaigai(at)ak(dot)jp(dot)nec(dot)com>  wrote:
>
>>> I don't think this is necessarily a good idea.  We might decide to treat
>>> both things separately in the future and it having them represented
>>> separately in the dump would prove useful.
>>
>> I agree. From design perspective, the single section approach is more
>> simple than dual section, but its change set is larger than the dual.
>
> OK.
>
>
> When I tested a custom dump with pg_restore, --clean&  --single-transaction
> will fail with the new dump format because it always call lo_unlink()
> even if the large object doesn't exist. It comes from dumpBlobItem:
>
> ! dumpBlobItem(Archive *AH, BlobInfo *binfo)
> ! 	appendPQExpBuffer(dquery, "SELECT lo_unlink(%s);\n", binfo->dobj.name);
>
> The query in DropBlobIfExists() could avoid errors -- should we use it here?
> | SELECT lo_unlink(oid) FROM pg_largeobject_metadata WHERE oid = %s;

Yes, we can use this query to handle --clean option.
I'll fix it soon.

> BTW, --clean option is ambiguous if combined with --data-only. Restoring
> large objects fails for the above reason if previous objects don't exist,
> but table data are restored *without* truncation of existing data. Will
> normal users expect TRUNCATE-before-load for --clean&  --data-only cases?
>
>      Present behaviors are;
>          Table data    - Appended. (--clean is ignored)
>          Large objects - End with an error if object doesn't exist.
>      IMO, ideal behaviors are:
>          Table data    - Truncate existing data and load new ones.
>          Large objects - Work like as MERGE (or REPLACE, UPSERT).
>
> Comments?

In the existing "BLOBS" section, it creates and restores large objects 
in same time. And, it also unlink existing large object (if exists)
just before restoring them, when --clean is given.

In my opinion, when --clean is given, it also should truncate the table
before restoring, even if --data-only is co-given.

Thanks,
-- 
KaiGai Kohei <kaigai(at)kaigai(dot)gr(dot)jp>

In response to

Responses

pgsql-hackers by date

Next:From: Michael MeskesDate: 2010-02-09 12:21:25
Subject: Re: buildfarm breakage
Previous:From: Jeroen VermeulenDate: 2010-02-09 12:08:54
Subject: Avoiding bad prepared-statement plans.

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