Largeobject Access Controls (r2460)
in [PgSql]
|
Prev: explain output infelicity in psql
Next: Winflex
From: Tom Lane on 18 Dec 2009 21:48 Robert Haas <robertmhaas(a)gmail.com> writes: > Oh. This is more complicated than it appeared on the surface. It > seems that the string "BLOB COMMENTS" actually gets inserted into > custom dumps somewhere, so I'm not sure whether we can just change it. > Was this issue discussed at some point before this was committed? > Changing it would seem to require inserting some backward > compatibility code here. Another option would be to add a separate > section for "BLOB METADATA", and leave "BLOB COMMENTS" alone. Can > anyone comment on what the Right Thing To Do is here? The BLOB COMMENTS label is, or was, correct for what it contained. If this patch has usurped it to contain other things I would argue that that is seriously wrong. pg_dump already has a clear notion of how to handle ACLs for objects. ACLs for blobs ought to be made to fit into that structure, not dumped in some random place because that saved a few lines of code. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Tom Lane on 18 Dec 2009 21:51 Robert Haas <robertmhaas(a)gmail.com> writes: > Part of what I'm confused about (and what I think should be documented > in a comment somewhere) is why we're using MVCC visibility in some > places but not others. In particular, there seem to be some bits of > the comment that imply that we do this for read but not for write, > which seems really strange. It may or may not actually be strange, > but I don't understand it. It is supposed to depend on whether you opened the blob for read only or for read write. Please do not tell me that this patch broke that; because if it did it broke pg_dump. This behavior is documented at least here: http://www.postgresql.org/docs/8.4/static/lo-interfaces.html#AEN36338 regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Robert Haas on 18 Dec 2009 22:05 On Fri, Dec 18, 2009 at 9:48 PM, Tom Lane <tgl(a)sss.pgh.pa.us> wrote: > Robert Haas <robertmhaas(a)gmail.com> writes: >> Oh. This is more complicated than it appeared on the surface. It >> seems that the string "BLOB COMMENTS" actually gets inserted into >> custom dumps somewhere, so I'm not sure whether we can just change it. >> Was this issue discussed at some point before this was committed? >> Changing it would seem to require inserting some backward >> compatibility code here. Another option would be to add a separate >> section for "BLOB METADATA", and leave "BLOB COMMENTS" alone. Can >> anyone comment on what the Right Thing To Do is here? > > The BLOB COMMENTS label is, or was, correct for what it contained. > If this patch has usurped it to contain other things It has. > I would argue > that that is seriously wrong. pg_dump already has a clear notion > of how to handle ACLs for objects. ACLs for blobs ought to be > made to fit into that structure, not dumped in some random place > because that saved a few lines of code. OK. Hopefully KaiGai or Takahiro can suggest a fix. Thanks, ....Robert -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Robert Haas on 18 Dec 2009 22:15 On Fri, Dec 18, 2009 at 9:51 PM, Tom Lane <tgl(a)sss.pgh.pa.us> wrote: > Robert Haas <robertmhaas(a)gmail.com> writes: >> Part of what I'm confused about (and what I think should be documented >> in a comment somewhere) is why we're using MVCC visibility in some >> places but not others. In particular, there seem to be some bits of >> the comment that imply that we do this for read but not for write, >> which seems really strange. It may or may not actually be strange, >> but I don't understand it. > > It is supposed to depend on whether you opened the blob for read only > or for read write. Please do not tell me that this patch broke that; > because if it did it broke pg_dump. > > This behavior is documented at least here: > http://www.postgresql.org/docs/8.4/static/lo-interfaces.html#AEN36338 Oh, I see. Thanks for the pointer. Having read that through, I can now say that the comments in the patch seem to imply that it attempted to preserve those semantics, but I can't swear that it did. I will take another look at it, but it might bear closer examination by someone with more MVCC-fu than myself. ....Robert -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: KaiGai Kohei on 20 Dec 2009 19:39
(2009/12/19 12:05), Robert Haas wrote: > On Fri, Dec 18, 2009 at 9:48 PM, Tom Lane<tgl(a)sss.pgh.pa.us> wrote: >> Robert Haas<robertmhaas(a)gmail.com> writes: >>> Oh. This is more complicated than it appeared on the surface. It >>> seems that the string "BLOB COMMENTS" actually gets inserted into >>> custom dumps somewhere, so I'm not sure whether we can just change it. >>> Was this issue discussed at some point before this was committed? >>> Changing it would seem to require inserting some backward >>> compatibility code here. Another option would be to add a separate >>> section for "BLOB METADATA", and leave "BLOB COMMENTS" alone. Can >>> anyone comment on what the Right Thing To Do is here? >> >> The BLOB COMMENTS label is, or was, correct for what it contained. >> If this patch has usurped it to contain other things > > It has. > >> I would argue >> that that is seriously wrong. pg_dump already has a clear notion >> of how to handle ACLs for objects. ACLs for blobs ought to be >> made to fit into that structure, not dumped in some random place >> because that saved a few lines of code. > > OK. Hopefully KaiGai or Takahiro can suggest a fix. Currently, BLOBS (and BLOB COMMENTS) section does not contain owner of the large objects, because it may press the local memory of pg_dump when the database contains massive amount of large objects. I believe it is the reason why we dump all the large objects in a single section. Correct? I don't think it is reasonable to dump all the large object with its individual section. However, we can categorize them per owner. In generally, we can assume the number of database users are smaller than the number of large objects. In other word, we can obtain the number of sections to be dumped as result of the following query: SELECT DISTINCT lomowner FROM pg_largeobject_metadata; Then, we can dump them per users. For earlier versions, all the large objects will be dumped in a single section with anonymous user. What's your opinion? -- OSS Platform Development Division, NEC KaiGai Kohei <kaigai(a)ak.jp.nec.com> -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers |