Re: Largeobject Access Controls (r2460)
От | KaiGai Kohei |
---|---|
Тема | Re: Largeobject Access Controls (r2460) |
Дата | |
Msg-id | 4B593B6B.8030003@ak.jp.nec.com обсуждение исходный текст |
Ответ на | Re: Largeobject Access Controls (r2460) (Takahiro Itagaki <itagaki.takahiro@oss.ntt.co.jp>) |
Ответы |
Re: Largeobject Access Controls (r2460)
(Tom Lane <tgl@sss.pgh.pa.us>)
|
Список | 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(). Thanks, (2010/01/21 19:42), Takahiro Itagaki wrote: > > KaiGai Kohei<kaigai@ak.jp.nec.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@ak.jp.nec.com>
Вложения
В списке pgsql-hackers по дате отправления: