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

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: 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-01-22 05:45:15
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
The attached patch is a revised version.

List of updates:
- cleanup: getBlobs() was renamed to getBlobOwners()
- cleanup: BlobsInfo was renamed to BlobOwnerInfo
- bugfix: pg_get_userbyid() in SQLs were replaced by username_subquery which
          constins a right subquery to obtain a username for the given id.
          It enables to run pg_dump under the concurrent role deletion.
- bugfix: Even if we give -a (--data-only) or -O (--no-owner) options,
          or archive does not contain Owner information, it tried to write
          out "ALTER LARGE OBJECT xxx OWNER TO ..." statement.
- bugfix: Even if we give -a (--data-only) or -x (--no-privileges) options,
          it tried to write out "BLOB ACLS" section.

The last two are the problems I noticed newly. It needs to introduce them.

The BLOB section can contain multiple definitions of large objects, unlike
any other object classes. It is also a reason why I had to group large
objects by database user.
The Owner tag of BLOB section is used to identify owner of the large objects
to be restored, and also used in --use-set-session-authorization mode.
However, we need to inject "ALTER LARGE OBJECT xxx OWNER TO ..." statement
for each lo_create() in _LoadBlobs(), because we cannot know how many large
objects are in the section before reading the archive.
But the last patch didn't pay mention about -a/-O option and an archive
which does not have Owner: tag.

The BLOB ACLS section is categorized to SECTION_DATA, it follows the manner
in BLOB COMMENTS behavior. In same reason, it has to handle the -a/-x option
by itself, but the last patch didn't handle it well.

BTW, here is a known issue. When we run pg_dump with -s(--schema-only),
it write out descriptions of regular object classes, but does not write
out the description of large objects.
It seems to me the description of large objects are considered as a part
of data, not properties. However, it might be inconsistent.

The reason of this behavior is all the BLOB dumps are categorized to
SECTION_DATA, so -s option informs pg_backup_archiver.c to skip routines
related to large objects.

However, it may be a time to consider this code into two steps.
In the schema section stage,
 - It creates empty large objects with lo_create()
 - It restores the description of the large objects.
 - It restores the ownership/privileges of the large objects.

In the date section stage,
 - It loads actual data contents into the empty large objects with lowrite().


(2010/01/21 19:42), Takahiro Itagaki wrote:
> KaiGai Kohei<kaigai(at)ak(dot)jp(dot)nec(dot)com>  wrote:
>>> I'm not sure whether we need to make groups for each owner of large objects.
>>> If I remember right, the primary issue was separating routines for dump
>>> BLOB ACLS from routines for BLOB COMMENTS, right? Why did you make the change?
>> When --use-set-session-authorization is specified, pg_restore tries to
>> change database role of the current session just before creation of
>> database objects to be restored.
>> Ownership of the database objects are recorded in the section header,
>> and it informs pg_restore who should be owner of the objects to be
>> restored in this section.
>> Then, pg_restore can generate ALTER xxx OWNER TO after creation, or
>> SET SESSION AUTHORIZATION before creation in runtime.
>> So, we cannot put creation of largeobjects with different ownership
>> in same section.
>> It is the reason why we have to group largeobjects by database user.
> Ah, I see.
> Then... What happen if we drop or rename roles who have large objects
> during pg_dump? Does the patch still work? It uses pg_get_userbyid().
> Regards,
> ---
> Takahiro Itagaki
> NTT Open Source Software Center

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

Attachment: pgsql-fix-pg_dump-blob-privs.2.patch
Description: text/x-patch (25.9 KB)

In response to


pgsql-hackers by date

Next:From: Heikki LinnakangasDate: 2010-01-22 06:33:50
Subject: Re: Streaming Replication on win32
Previous:From: Robert HaasDate: 2010-01-22 04:34:41
Subject: Re: quoting psql varible as identifier

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