Re: [HACKERS] stat() vs cygwin
Bruce Momjian schrieb: Andrew Dunstan wrote: Bruce Momjian wrote: Andrew Dunstan wrote: Alvaro Herrera wrote: Andrew Dunstan wrote: I'm confused. There is a Cygwin member of buildfarm, working quite happily. Can you point me to the exact patch in question, please? I thought we resolved the matter of stat() ages ago. http://archives.postgresql.org/message-id/4865F707.6010702%40x-ray.at That patch is NOT about $subject. In fact, if you read that whole thread you will see here http://archives.postgresql.org/pgsql-hackers/2008-06/msg00915.php that I conducted a test on Cygwin and found it was not suffering from the problem we fixed on WIN32. AFAICT Reini's patch is about fixing OpenSSL and possibly some other options on Cygwin. It was rejected because it had other problems, but is not indicative of a fundamental problem on Cygwin. There is no reason I am aware of that we should declare Cygwin no longer supported, no matter how much its continued existence apparently annoys a few people :-) . Oh, good, thanks for clearing that up. So should we just document that OpenSSL doesn't work on Cygwin and call this item closed? This item should be closed. We should see if Reini can submit an acceptable patch for OpenSSL. I have documented that OpenSSL is not supported for Cygwin. Excuse me? openssl works fine on cygwin, even without the testing patch which was attached. This patch only tried to optimize openssl socket handling equivalent to WIN32. Please revert that documentation. The current configure args of the official postgresql packages are: --enable-nls --with-openssl --with-perl --with-python --with-ldap The problem is just that SSPI auth does not compile on cygwin. -- Reini Urban http://phpwiki.org/ http://murbreak.at/ -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] Problem building from source on Windows
Hi, I am trying to build Postgres (8.3.5) from source on Windows XP using Visual Studio 2005 as per the instructions in the PostgreSQL documentation. The problem is that the uuild.lib and uuid.h files are not tracable though I have done the requisite downloads from uuid and ossp link specified in the documentation. Please help. Regards Swati -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Problem building from source on Windows
Hi. Ooops, I forgot adjustment completely to Ralf-san. Although Ralf-san understood at the time, he demanded to wait very busily sorry. some infomation. this was due to be contained by 1.6.3/4. This is build the MinGW + gcc. http://winpg.jp/~saito/pg_work/OSSP_win32/ as for MS-VC++, http://winpg.jp/~saito/pg_work/OSSP_win32/msvc/ I will try adjustment again. Regards, Hiroshi Saito - Original Message - From: "Ms swati chande" Hi, I am trying to build Postgres (8.3.5) from source on Windows XP using Visual Studio 2005 as per the instructions in the PostgreSQL documentation. The problem is that the uuild.lib and uuid.h files are not tracable though I have done the requisite downloads from uuid and ossp link specified in the documentation. Please help. Regards Swati -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Query progress indication - an implementation
On Fri, Jun 26, 2009 at 3:37 AM, Scara Maccai wrote: > Hi all, > > following the link in > > http://wiki.postgresql.org/wiki/Query_progress_indication > > but mostly: > > http://www.postech.ac.kr/~swhwang/progress2.pdf [1] > > I'm trying to write an implementation of the "dne" method in postgresql. > > I added another column to the pg_stat_get_activity function to report the > percentage of work done for the query (of course, any other method could be > used... the way the percentage is reported to the user can be easily changed). > > I attached a first patch (just to see if anyone is interested, the work is by > no means finished). > > I guess I did a lot of mistakes, since I don't know anything about postgresql > code... > > 1) the progress indicator can be eliminated at runtime; this could be done > with another runtime flag (at the moment is always on) > > 2) I added a new structure (Progress) to PlanState to keep all the info about > execution progress > > 3) I needed a pointer to the root of the PlanStates, to be able to calculate > the total progress of the query tree (I bet this pointer was already > available somewhere, but I couldn't find where...) > > 4) sub-plans are not included yet (well, just to be honest, I don't really > know what postgresql means with those... :) ) > > 5) the percentage is updated at most every second (can be easily changed) > > 6) the methods to adjust upper/lower bounds in [1] are not implemented yet > (but that shouldn't be a problem) > > 7) the "spilled tuples" handling in [1] is not supported yet > > 8) only hash join, loop join, aggregate, sequence scans are implemented at > the moment > > 9) I added another flag (EXEC_FLAG_DRIVER_BRANCH) in executor.h to signal to > the sub-nodes if they are part of a branch that will contain a driver node > (for example, inner subtree of a Nested Loops join is not a driver branch). I > guess this could be done better at Plan level (instead of PlanState), but > this way less code has to be changed > > 10) at the moment all driver nodes have the same "work_per_tuple=1", but this > could be changed (for example, CPU-intensive driver nodes could have a > smaller work_per_tuple value) > > Well, some (very early) tests on a tpcd db showed it works as expected (well, > I only did very few tests...) You might want to take a look at this: http://wiki.postgresql.org/wiki/Submitting_a_Patch The project style is not to use C++-style comments, and you should eliminate all of the unnecessary diff hunks from your patch (like files that have only comment or whitespace changes). Also, it is requested that patches be submitted in context diff format and added to the CommitFest wiki here: http://wiki.postgresql.org/wiki/CommitFest_2009-First As to the content of the patch, I think that what you are doing is comparing the actual number of "operations" with the expected number of operations. If that's correct, I'm not sure it's really all that useful, because it will only give you accurate percentage-of-completion information when the estimates are correct. But when the estimates are correct, you probably have a pretty good idea how long the query will take to run anyway. When the estimates are off, you'll find that the actual number of operations is more than the expected number of operations, but that won't really tell you how far you have to go. The only other use case I can think of for functionality of this type is some kind of dashboard view on a system with very long-running queries, where you want to see how far you have yet to go on each one (maybe to approximate when you can submit the next one) without having detailed knowledge of how expensive each individual query was project to be. But that's a pretty narrow use case, and I'm not sure it really justifies the overhead of instrumenting every query in this way. For a fraction of the run-time cost, you could include the estimated total cost of the query in the pg_stat_activity output, which would let the user do much the same thing presuming that they have some knowledge of the usual ratio between costs and execution times. Greg Stark was (is?) working on a way to get EXPLAIN-ANALYZE type statistics on running queries; you might want to take a look at some of that work and see what you think. http://wiki.postgresql.org/wiki/Greg_Stark%27s_Development_Projects#EXPLAIN_queries_in_progress ...Robert -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] pre-proposal: permissions made easier
I'd like some brief feedback on this idea before I try to make a real proposal. The use case is this: You have an application with several roles: * admin user - owns all the objects related to that application * normal user - INSERT/UPDATE/DELETE plus sequence usage * read-only user - for reporting The problem is managing all the permissions requires a lot of care, and it's difficult to easily verify that all the permissions are set as you expect on all of the objects. Because it's more difficult to manage, I think many people just have a single user for all of these things. My idea is to have a "GRANT mask": CREATE ROLE foo_ro GRANT (SELECT ON TABLE, USAGE ON SCHEMA) FROM foo; [syntax not meant as a real proposal yet, just for illustration] And foo_ro would get the SELECT ON TABLE and USAGE ON SCHEMA privileges from foo, but not any INSERT privileges. That way, you can add roles without having to do a GRANT on each object separately. And, more importantly, you can pretty easily observe that the privileges are what you expect without inspecting the objects individually. This idea is meant to be a better solution than the "GRANT ... *" that MySQL offers. Questions: 1. Is this a reasonable approach from a security standpoint, or is it fundamentally flawed? 2. Does it violate the SQL standard? 3. Is it completely orthogonal to "IN ROLE" and "INHERITS", or should they be made to work together somehow? Regards, Jeff Davis -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] pre-proposal: permissions made easier
Jeff Davis wrote: > > I'd like some brief feedback on this idea before I try to make a real > proposal. > > The use case is this: > > You have an application with several roles: > * admin user - owns all the objects related to that application > * normal user - INSERT/UPDATE/DELETE plus sequence usage > * read-only user - for reporting > > The problem is managing all the permissions requires a lot of care, and > it's difficult to easily verify that all the permissions are set as you > expect on all of the objects. Because it's more difficult to manage, I > think many people just have a single user for all of these things. > > My idea is to have a "GRANT mask": > > CREATE ROLE foo_ro GRANT (SELECT ON TABLE, USAGE ON SCHEMA) FROM foo; > > [syntax not meant as a real proposal yet, just for illustration] > > And foo_ro would get the SELECT ON TABLE and USAGE ON SCHEMA privileges > from foo, but not any INSERT privileges. That way, you can add roles > without having to do a GRANT on each object separately. And, more > importantly, you can pretty easily observe that the privileges are what > you expect without inspecting the objects individually. > > This idea is meant to be a better solution than the "GRANT ... *" that > MySQL offers. > > Questions: > > 1. Is this a reasonable approach from a security standpoint, or is it > fundamentally flawed? It seems to me that you're duplicating the functionality that is already possible by using groups. i.e. grant the permissions to the group and add users to the group as appropriate. -- Bill Moran http://www.potentialtech.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] dependencies for generated header files
Hi, I think that our dependencies for generated header files (gram.h, fmgroids.h, probes.h) are not as good as they could be. What we do right now is make src/backend/Makefile rebuild these before recursing through its subdirectories. This works OK for a top-level make, but if you run make further down in the tree (like under src/backend/commands) it won't necessarily rebuild everything that it should. The attached patch moves some of this logic from src/backend/Makefile to src/Makefile.global.in. That way, if you --enable-depend and then do something like "touch src/include/catalog/pg_proc.h" and then "cd src/backend/commands; make vacuum.o", it rebuilds fmgroids.h and then recompiles vacuum.c. Under HEAD, it just tells you that vacuum.o is up to date. I have tested this on vpath and non-vpath builds, with and without --enable-depend. ...Robert *** a/src/Makefile.global.in --- b/src/Makefile.global.in *** *** 517,522 $(top_builddir)/src/interfaces/ecpg/include/ecpg_config.h: $(top_builddir)/src/i --- 517,551 $(top_builddir)/config.status: $(top_srcdir)/configure cd $(top_builddir) && ./config.status --recheck + # Generated header files need dependencies here to ensure that everything + # which depends on them gets rebuilt when necessary. Note that it's important + # we match the dependencies shown in the subdirectory makefiles! + $(top_srcdir)/src/backend/parser/gram.h: $(top_srcdir)/src/backend/parser/gram.y + $(MAKE) -C $(top_builddir)/src/backend/parser gram.h + + $(top_builddir)/src/backend/utils/fmgroids.h: $(top_srcdir)/src/backend/utils/Gen_fmgrtab.sh $(top_srcdir)/src/include/catalog/pg_proc.h + $(MAKE) -C $(top_builddir)/src/backend/utils fmgroids.h + + $(top_builddir)/src/backend/utils/probes.h: $(top_srcdir)/src/backend/utils/probes.d + $(MAKE) -C $(top_builddir)/src/backend/utils probes.h + + # Make symlinks for these headers in the include directory. That way + # we can cut down on the -I options. Also, a symlink is automatically + # up to date when we update the base file. + + $(top_builddir)/src/include/parser/gram.h: $(top_srcdir)/src/backend/parser/gram.h + prereqdir=`cd $(dir $<) >/dev/null && pwd` && \ + cd $(dir $@) && rm -f $(notdir $@) && \ + $(LN_S) "$$prereqdir/$(notdir $<)" . + + $(top_builddir)/src/include/utils/fmgroids.h: $(top_builddir)/src/backend/utils/fmgroids.h + cd $(dir $@) && rm -f $(notdir $@) && \ + $(LN_S) ../../../src/backend/utils/fmgroids.h . + + $(top_builddir)/src/include/utils/probes.h: $(top_builddir)/src/backend/utils/probes.h + cd $(dir $@) && rm -f $(notdir $@) && \ + $(LN_S) ../../../src/backend/utils/probes.h . + endif # not PGXS *** a/src/backend/Makefile --- b/src/backend/Makefile *** *** 113,150 $(SUBDIRS:%=%-recursive): $(top_builddir)/src/include/parser/gram.h $(top_buildd postgres.o: $(OBJS) $(CC) $(LDREL) $(LDFLAGS) $(call expand_subsys,$^) $(LIBS) -o $@ - - # The following targets are specified in make commands that appear in - # the make files in our subdirectories. Note that it's important we - # match the dependencies shown in the subdirectory makefiles! - - $(srcdir)/parser/gram.h: parser/gram.y - $(MAKE) -C parser gram.h - - utils/fmgroids.h: utils/Gen_fmgrtab.sh $(top_srcdir)/src/include/catalog/pg_proc.h - $(MAKE) -C utils fmgroids.h - - utils/probes.h: utils/probes.d - $(MAKE) -C utils probes.h - - # Make symlinks for these headers in the include directory. That way - # we can cut down on the -I options. Also, a symlink is automatically - # up to date when we update the base file. - - $(top_builddir)/src/include/parser/gram.h: $(srcdir)/parser/gram.h - prereqdir=`cd $(dir $<) >/dev/null && pwd` && \ - cd $(dir $@) && rm -f $(notdir $@) && \ - $(LN_S) "$$prereqdir/$(notdir $<)" . - - $(top_builddir)/src/include/utils/fmgroids.h: utils/fmgroids.h - cd $(dir $@) && rm -f $(notdir $@) && \ - $(LN_S) ../../../$(subdir)/utils/fmgroids.h . - - $(top_builddir)/src/include/utils/probes.h: utils/probes.h - cd $(dir $@) && rm -f $(notdir $@) && \ - $(LN_S) ../../../$(subdir)/utils/probes.h . - - ifeq ($(PORTNAME), solaris) utils/probes.o: utils/probes.d $(SUBDIROBJS) $(DTRACE) $(DTRACEFLAGS) -C -G -s $(call expand_subsys,$^) -o $@ --- 113,118 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] pre-proposal: permissions made easier
On Sun, 2009-06-28 at 14:12 -0400, Bill Moran wrote: > It seems to me that you're duplicating the functionality that is already > possible by using groups. i.e. grant the permissions to the group and > add users to the group as appropriate. Take the use case in my email. You would have to grant a specific set of permissions to each of 3 groups for every object created. The problem is not having many users that all share the exact same permissions; the problem is having to assign separate permissions on a per-object basis. Regards, Jeff Davis -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] pre-proposal: permissions made easier
Jeff Davis writes: > My idea is to have a "GRANT mask": > CREATE ROLE foo_ro GRANT (SELECT ON TABLE, USAGE ON SCHEMA) FROM foo; You haven't really explained what "foo" is here. If it's a single object then I don't think this offers any leverage. If it's a placeholder or class representative of some kind, then maybe, but in that case you've entirely failed to convey the point ... regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] pre-proposal: permissions made easier
On Sun, 2009-06-28 at 14:32 -0400, Tom Lane wrote: > Jeff Davis writes: > > My idea is to have a "GRANT mask": > > CREATE ROLE foo_ro GRANT (SELECT ON TABLE, USAGE ON SCHEMA) FROM foo; > > You haven't really explained what "foo" is here. If it's a single > object then I don't think this offers any leverage. If it's a > placeholder or class representative of some kind, then maybe, but > in that case you've entirely failed to convey the point ... > I meant for "foo" to be a user. "foo_ro" would be the read-only version, who has a strict subset of foo's permissions. Regards, Jeff Davis -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] pre-proposal: permissions made easier
Jeff Davis writes: > On Sun, 2009-06-28 at 14:32 -0400, Tom Lane wrote: >> Jeff Davis writes: >>> My idea is to have a "GRANT mask": >>> CREATE ROLE foo_ro GRANT (SELECT ON TABLE, USAGE ON SCHEMA) FROM foo; >> >> You haven't really explained what "foo" is here. > I meant for "foo" to be a user. "foo_ro" would be the read-only version, > who has a strict subset of foo's permissions. I see. It seems like rather a complicated (and expensive) mechanism for a pretty narrow use-case. It'd only help for the cases where you could define your permissions requirements that way. I agree that there are some such cases, but I think real-world problems tend to be a bit more complicated than that. I fear people would soon want exceptions to the "strict subset" rule; and once you put that in, the conceptual simplicity disappears, as does the ability to easily verify what the set of GRANTs is doing. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] pre-proposal: permissions made easier
On Sun, 2009-06-28 at 14:56 -0400, Tom Lane wrote: > > I meant for "foo" to be a user. "foo_ro" would be the read-only version, > > who has a strict subset of foo's permissions. > > I see. It seems like rather a complicated (and expensive) mechanism > for a pretty narrow use-case. It'd only help for the cases where you > could define your permissions requirements that way. I agree that > there are some such cases, but I think real-world problems tend to be > a bit more complicated than that. I fear people would soon want > exceptions to the "strict subset" rule; and once you put that in, > the conceptual simplicity disappears, as does the ability to easily > verify what the set of GRANTs is doing. As soon as the permissions scheme gets more complicated than what I suggest, I agree that the user is better off just using GRANTs on a per-object basis. You could still GRANT directly to the user foo_ro -- for instance if your reporting user needs to join against some other table -- but that could get complicated if you take it too far. The users I'm targeting with my idea are: * Users who have a fairly simple set of users and permissions, and who want a simple picture of the permissions in their system for reassurance/verification. * Users who come from MySQL every once in a while, annoyed that we don't support "GRANT ... *" syntax. * Users who are savvy enough to use access control, but don't have rigorous procedures for making DDL changes. Some of these users depend on an ORM or similar to make DDL changes for them, and this idea gives them a workaround. * Users who don't currently use separate permissions, but might start if it's simpler to do simple things. Maybe I should shop this idea on -general and see how many people's problems would actually be solved? The performance issue is something to consider, but I think it would just be an extra catalog lookup (for each level), and the users of this feature would probably be willing to pay that cost. Regards, Jeff Davis -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] pre-proposal: permissions made easier
On Sun, Jun 28, 2009 at 12:52:54PM -0700, Jeff Davis wrote: > On Sun, 2009-06-28 at 14:56 -0400, Tom Lane wrote: > > > I meant for "foo" to be a user. "foo_ro" would be the read-only > > > version, who has a strict subset of foo's permissions. > > > > I see. It seems like rather a complicated (and expensive) > > mechanism for a pretty narrow use-case. It'd only help for the > > cases where you could define your permissions requirements that > > way. I agree that there are some such cases, but I think > > real-world problems tend to be a bit more complicated than that. > > I fear people would soon want exceptions to the "strict subset" > > rule; and once you put that in, the conceptual simplicity > > disappears, as does the ability to easily verify what the set of > > GRANTs is doing. > > As soon as the permissions scheme gets more complicated than what I > suggest, I agree that the user is better off just using GRANTs on a > per-object basis. You could still GRANT directly to the user foo_ro > -- for instance if your reporting user needs to join against some > other table -- but that could get complicated if you take it too > far. > > The users I'm targeting with my idea are: * Users who have a fairly > simple set of users and permissions, and who want a simple picture > of the permissions in their system for reassurance/verification. I don't know of a case that started simple and stayed there without a lot of design up front. In other words, those who'd benefit by such a thing are generally not those who'd want a shortcut. > * Users who come from MySQL every once in a while, annoyed that we > don't support "GRANT ... *" syntax. I'm missing what's wrong with a wild-card GRANT syntax for this case. > * Users who are savvy enough to use access control, but don't have > rigorous procedures for making DDL changes. Some of these users > depend on an ORM or similar to make DDL changes for them, and this > idea gives them a workaround. Such ORMs are a problem, and accommodating them only aggravates it. :) > * Users who don't currently use separate permissions, but might > start if it's simpler to do simple things. This is a matter of education, not tools. The problem here is not that permissions are unavailable, but that people are failing to use them. > Maybe I should shop this idea on -general and see how many people's > problems would actually be solved? There are a few issues at hand here, some of which could get addressed by polling on -general: * SQL standards compliance (clearly not a -general issue) * Utility to current users (might be addressable on -general) * Utility to future users (not on -general) * Trade-offs such a solution would impose (possibly on -general and the ever-popular * Stuff I didn't think of ;) > The performance issue is something to consider, but I think it would > just be an extra catalog lookup (for each level), and the users of > this feature would probably be willing to pay that cost. Where did this come up? Cheers, David. -- David Fetter http://fetter.org/ Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter Skype: davidfetter XMPP: david.fet...@gmail.com Remember to vote! Consider donating to Postgres: http://www.postgresql.org/about/donate -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] pre-proposal: permissions made easier
On Sun, Jun 28, 2009 at 2:07 PM, Jeff Davis wrote: > I'd like some brief feedback on this idea before I try to make a real > proposal. > > The use case is this: > > You have an application with several roles: > * admin user - owns all the objects related to that application > * normal user - INSERT/UPDATE/DELETE plus sequence usage > * read-only user - for reporting > > The problem is managing all the permissions requires a lot of care, and > it's difficult to easily verify that all the permissions are set as you > expect on all of the objects. Because it's more difficult to manage, I > think many people just have a single user for all of these things. > > My idea is to have a "GRANT mask": > > CREATE ROLE foo_ro GRANT (SELECT ON TABLE, USAGE ON SCHEMA) FROM foo; > > [syntax not meant as a real proposal yet, just for illustration] > > And foo_ro would get the SELECT ON TABLE and USAGE ON SCHEMA privileges > from foo, but not any INSERT privileges. That way, you can add roles > without having to do a GRANT on each object separately. And, more > importantly, you can pretty easily observe that the privileges are what > you expect without inspecting the objects individually. > > This idea is meant to be a better solution than the "GRANT ... *" that > MySQL offers. > > Questions: > > 1. Is this a reasonable approach from a security standpoint, or is it > fundamentally flawed? Reasonable. > 2. Does it violate the SQL standard? Don't know. > 3. Is it completely orthogonal to "IN ROLE" and "INHERITS", or should > they be made to work together somehow? Maybe GRANT foo (SELECT, USAGE) TO foo_ro, meaning "grant restricted membership in role foo to foo_ro, encompassing only the SELECT and USAGE privileges of foo"? I do to some degree share Tom's worry that this is an idiosyncratic solution to a tiny subset of the problem space. On the other hand, I have to admit I've needed to do this exact thing, so I wrote a script to issue the necessary grant statements. Then I discovered that whenever I created any new objects (most frequently drop and recreate of any of the relevant views) the permissions got screwed up, so I crontabbed the script to run every 20 minutes. This works, but it doesn't bleed elegance. I'm not sure what the right things to do in this area are, but I'm glad that you (and others, like Stephen Frost) are thinking about it... ...Robert -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] pre-proposal: permissions made easier
David Fetter wrote: * Users who come from MySQL every once in a while, annoyed that we don't support "GRANT ... *" syntax. I'm missing what's wrong with a wild-card GRANT syntax for this case. Without a major change in the way we do permissions, it will not work prospectively. We have no way ATM to store permissions for an object that does not currently exist. cheers andrew -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] pre-proposal: permissions made easier
On Sun, Jun 28, 2009 at 05:27:19PM -0400, Andrew Dunstan wrote: > > > David Fetter wrote: >> >>> * Users who come from MySQL every once in a while, annoyed that >>> we don't support "GRANT ... *" syntax. >>> >> >> I'm missing what's wrong with a wild-card GRANT syntax for this >> case. > > Without a major change in the way we do permissions, it will not > work prospectively. We have no way ATM to store permissions for an > object that does not currently exist. There have been previous discussions of prospective permissions changes. Are we restarting them here? Cheers, David. -- David Fetter http://fetter.org/ Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter Skype: davidfetter XMPP: david.fet...@gmail.com Remember to vote! Consider donating to Postgres: http://www.postgresql.org/about/donate -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] pre-proposal: permissions made easier
On Sun, 2009-06-28 at 17:23 -0400, Robert Haas wrote: > I do to some degree share Tom's worry that this is an idiosyncratic > solution to a tiny subset of the problem space. I share the concern. However, I don't know if it's a "tiny subset" or not; I think we'll have to get some feedback from users to really know. > On the other hand, I > have to admit I've needed to do this exact thing, so I wrote a script > to issue the necessary grant statements. Then I discovered that > whenever I created any new objects (most frequently drop and recreate > of any of the relevant views) the permissions got screwed up, so I > crontabbed the script to run every 20 minutes. This works, but it > doesn't bleed elegance. I have written scripts to handle some of this in the past, and it's always awkward. That's what made me start thinking about alternatives. Regards, Jeff Davis -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] pre-proposal: permissions made easier
* David Fetter (da...@fetter.org) wrote: > On Sun, Jun 28, 2009 at 05:27:19PM -0400, Andrew Dunstan wrote: > > Without a major change in the way we do permissions, it will not > > work prospectively. We have no way ATM to store permissions for an > > object that does not currently exist. > > There have been previous discussions of prospective permissions > changes. Are we restarting them here? Having default permissions for new objects (something a couple of us are working towards) would help with this situation some. I don't think the ground Jeff's proposal would cover is entirely covered by just having default permissions though. Stephen signature.asc Description: Digital signature
Re: [HACKERS] pre-proposal: permissions made easier
On Sun, 2009-06-28 at 14:16 -0700, David Fetter wrote: > > The users I'm targeting with my idea are: * Users who have a fairly > > simple set of users and permissions, and who want a simple picture > > of the permissions in their system for reassurance/verification. > > I don't know of a case that started simple and stayed there without a > lot of design up front. In other words, those who'd benefit by such a > thing are generally not those who'd want a shortcut. I think that the 3 user types I outlined are a fairly reasonable permissions scheme for a significant set of applications. I have used that in the past, and generally speaking, I didn't need to make lots of strange exceptions. > > * Users who don't currently use separate permissions, but might > > start if it's simpler to do simple things. > > This is a matter of education, not tools. The problem here is not > that permissions are unavailable, but that people are failing to use > them. I don't think education is the answer. These users aren't necessarily ignorant, but just don't want to hack up scripts to manage permissions for what they perceive are simple schemes. If the user imagines a well-defined but simple scheme, and it takes a lot of awkward scripts to accomplish it, I think we've missed something. A "reporting user" seems like a perfectly normal kind of user to create, and yet it's very awkward to do. > > The performance issue is something to consider, but I think it would > > just be an extra catalog lookup (for each level), and the users of > > this feature would probably be willing to pay that cost. > > Where did this come up? Tom mentioned that it might be expensive to check permissions, which I assume was due to the extra catalog lookups required. I don't think it's a major concern, nor would it affect normal permissions checks, unless I missed something. Regards, Jeff Davis -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] pre-proposal: permissions made easier
On Sun, 2009-06-28 at 14:38 -0700, David Fetter wrote: > There have been previous discussions of prospective permissions > changes. Are we restarting them here? > I don't remember seeing anything in those discussions that really materialized. Can you point me to something that you think is a better alternative than my idea? Regards, Jeff Davis -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] pre-proposal: permissions made easier
On Sun, 2009-06-28 at 18:03 -0400, Stephen Frost wrote: > * David Fetter (da...@fetter.org) wrote: > > On Sun, Jun 28, 2009 at 05:27:19PM -0400, Andrew Dunstan wrote: > > > Without a major change in the way we do permissions, it will not > > > work prospectively. We have no way ATM to store permissions for an > > > object that does not currently exist. > > > > There have been previous discussions of prospective permissions > > changes. Are we restarting them here? > > Having default permissions for new objects (something a couple of us are > working towards) would help with this situation some. I don't think the > ground Jeff's proposal would cover is entirely covered by just having > default permissions though. > One case that it would not cover is creating new roles that you would like to have access to existing objects. Defaults may be useful independently, though, so I think the proposals are overlapping, but generally different. Regards, Jeff Davis -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] pre-proposal: permissions made easier
David Fetter wrote: On Sun, Jun 28, 2009 at 05:27:19PM -0400, Andrew Dunstan wrote: David Fetter wrote: * Users who come from MySQL every once in a while, annoyed that we don't support "GRANT ... *" syntax. I'm missing what's wrong with a wild-card GRANT syntax for this case. Without a major change in the way we do permissions, it will not work prospectively. We have no way ATM to store permissions for an object that does not currently exist. There have been previous discussions of prospective permissions changes. Are we restarting them here? *shrug* It's not on the TODO list. I recall it being raised from time to time but I certainly don't recall a consensus that it should be done, nor how, so if you're implying that such a thing is a settled decision I suspect you're not entirely correct. Of course, my memory has been known to have errors ... cheers andrew -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] pre-proposal: permissions made easier
On Sun, Jun 28, 2009 at 06:28:32PM -0400, Andrew Dunstan wrote: > > > David Fetter wrote: >> On Sun, Jun 28, 2009 at 05:27:19PM -0400, Andrew Dunstan wrote: >> >>> David Fetter wrote: >>> > * Users who come from MySQL every once in a while, annoyed that > we don't support "GRANT ... *" syntax. > I'm missing what's wrong with a wild-card GRANT syntax for this case. >>> Without a major change in the way we do permissions, it will not >>> work prospectively. We have no way ATM to store permissions for an >>> object that does not currently exist. >>> >> >> There have been previous discussions of prospective permissions >> changes. Are we restarting them here? > > *shrug* > > It's not on the TODO list. I recall it being raised from time to time > but I certainly don't recall a consensus that it should be done, nor > how, That was my recollection, too. > so if you're implying that such a thing is a settled decision I > suspect you're not entirely correct. By no means. > Of course, my memory has been known to have errors ... Same with mine ;) Cheers, David. -- David Fetter http://fetter.org/ Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter Skype: davidfetter XMPP: david.fet...@gmail.com Remember to vote! Consider donating to Postgres: http://www.postgresql.org/about/donate -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] [PATCH] [v8.5] Security checks on largeobjects
Bernd Helmle wrote:
> --On 26. Juni 2009 13:08:37 +0900 KaiGai Kohei
> wrote:
>
>> * Is the named large object (including fully qualified one) worth?
>>It will enables us to specify a largeobject with human readable
>>identifier string.
>
> I don't understand the notion of this. Does this mean you can create a
> LO with an identifier string, generated from (e.g.) your application?
Yes, it intends to assign an identifier string not only numeric
large object identifier. The identifier string can be qualified
with a certain namespace as follows.
E.g)
SELECT lo_open('my_picture01', x'4'::int);
SELECT lo_create('pg_temp.my_musid02');
In the later case, the new largeobject will be reclaimed after
the session closed due to the temporary namespace.
Thanks,
--
OSS Platform Development Division, NEC
KaiGai Kohei
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] dependencies for generated header files
On Sun, Jun 28, 2009 at 2:21 PM, Robert Haas wrote: > I think that our dependencies for generated header files (gram.h, > fmgroids.h, probes.h) are not as good as they could be. What we do > right now is make src/backend/Makefile rebuild these before recursing > through its subdirectories. This works OK for a top-level make, but > if you run make further down in the tree (like under > src/backend/commands) it won't necessarily rebuild everything that it > should. > > The attached patch moves some of this logic from src/backend/Makefile > to src/Makefile.global.in. That way, if you --enable-depend and then > do something like "touch src/include/catalog/pg_proc.h" and then "cd > src/backend/commands; make vacuum.o", it rebuilds fmgroids.h and then > recompiles vacuum.c. Under HEAD, it just tells you that vacuum.o is > up to date. > > I have tested this on vpath and non-vpath builds, with and without > --enable-depend. Woops. It seems that patch generates some warnings on a vpath build which I failed to notice. Corrected version that guards against same is attached. ...Robert *** a/src/Makefile.global.in --- b/src/Makefile.global.in *** *** 517,522 $(top_builddir)/src/interfaces/ecpg/include/ecpg_config.h: $(top_builddir)/src/i --- 517,555 $(top_builddir)/config.status: $(top_srcdir)/configure cd $(top_builddir) && ./config.status --recheck + # Generated header files need dependencies here to ensure that everything + # which depends on them gets rebuilt when necessary. Note that it's important + # we match the dependencies shown in the subdirectory makefiles! + ifneq ($(subdir),src/backend/parser) + $(top_srcdir)/src/backend/parser/gram.h: $(top_srcdir)/src/backend/parser/gram.y + $(MAKE) -C $(top_builddir)/src/backend/parser gram.h + endif + + ifneq ($(subdir),src/backend/utils) + $(top_builddir)/src/backend/utils/fmgroids.h: $(top_srcdir)/src/backend/utils/Gen_fmgrtab.sh $(top_srcdir)/src/include/catalog/pg_proc.h + $(MAKE) -C $(top_builddir)/src/backend/utils fmgroids.h + + $(top_builddir)/src/backend/utils/probes.h: $(top_srcdir)/src/backend/utils/probes.d + $(MAKE) -C $(top_builddir)/src/backend/utils probes.h + endif + + # Make symlinks for these headers in the include directory. That way + # we can cut down on the -I options. Also, a symlink is automatically + # up to date when we update the base file. + + $(top_builddir)/src/include/parser/gram.h: $(top_srcdir)/src/backend/parser/gram.h + prereqdir=`cd $(dir $<) >/dev/null && pwd` && \ + cd $(dir $@) && rm -f $(notdir $@) && \ + $(LN_S) "$$prereqdir/$(notdir $<)" . + + $(top_builddir)/src/include/utils/fmgroids.h: $(top_builddir)/src/backend/utils/fmgroids.h + cd $(dir $@) && rm -f $(notdir $@) && \ + $(LN_S) ../../../src/backend/utils/fmgroids.h . + + $(top_builddir)/src/include/utils/probes.h: $(top_builddir)/src/backend/utils/probes.h + cd $(dir $@) && rm -f $(notdir $@) && \ + $(LN_S) ../../../src/backend/utils/probes.h . + endif # not PGXS *** a/src/backend/Makefile --- b/src/backend/Makefile *** *** 113,150 $(SUBDIRS:%=%-recursive): $(top_builddir)/src/include/parser/gram.h $(top_buildd postgres.o: $(OBJS) $(CC) $(LDREL) $(LDFLAGS) $(call expand_subsys,$^) $(LIBS) -o $@ - - # The following targets are specified in make commands that appear in - # the make files in our subdirectories. Note that it's important we - # match the dependencies shown in the subdirectory makefiles! - - $(srcdir)/parser/gram.h: parser/gram.y - $(MAKE) -C parser gram.h - - utils/fmgroids.h: utils/Gen_fmgrtab.sh $(top_srcdir)/src/include/catalog/pg_proc.h - $(MAKE) -C utils fmgroids.h - - utils/probes.h: utils/probes.d - $(MAKE) -C utils probes.h - - # Make symlinks for these headers in the include directory. That way - # we can cut down on the -I options. Also, a symlink is automatically - # up to date when we update the base file. - - $(top_builddir)/src/include/parser/gram.h: $(srcdir)/parser/gram.h - prereqdir=`cd $(dir $<) >/dev/null && pwd` && \ - cd $(dir $@) && rm -f $(notdir $@) && \ - $(LN_S) "$$prereqdir/$(notdir $<)" . - - $(top_builddir)/src/include/utils/fmgroids.h: utils/fmgroids.h - cd $(dir $@) && rm -f $(notdir $@) && \ - $(LN_S) ../../../$(subdir)/utils/fmgroids.h . - - $(top_builddir)/src/include/utils/probes.h: utils/probes.h - cd $(dir $@) && rm -f $(notdir $@) && \ - $(LN_S) ../../../$(subdir)/utils/probes.h . - - ifeq ($(PORTNAME), solaris) utils/probes.o: utils/probes.d $(SUBDIROBJS) $(DTRACE) $(DTRACEFLAGS) -C -G -s $(call expand_subsys,$^) -o $@ --- 113,118 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] query cancel issues in contrib/dblink
Merlin Moncure wrote: > Takahiro wrote: > > contrib/dblink seems to have no treatments for query cancels. > > (1) Users need to wait for completion of remote query. > > (2) PGresult objects will be memory leak. Here is a patch to fix the issues. I hope the fixes will be ported to older versions if possible. (1) is fixed by using non-blocking APIs in libpq. I think we should always use non-blocking APIs even if the dblink function itself is a blocking-function. (2) is fixed by RegisterXactCallback(AtEOXact_dblink). However, there might be any better solutions -- for example, ResourceOwner framework. > > For (1), asynchronous libpq functions should be used instead of blocking > > ones, and wait for the remote query using a loop with > > CHECK_FOR_INTERRUPTS(). > > How would you structure this loop exactly? Please check execute_query() and wait_for_result() in the patch. Regards, --- ITAGAKI Takahiro NTT Open Source Software Center dblink.patch Description: Binary data -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Query progress indication - an implementation
On Sunday 28 June 2009 20:38:59 Robert Haas wrote: > The only other use case I can think of for functionality of this type > is some kind of dashboard view on a system with very long-running > queries, where you want to see how far you have yet to go on each one > (maybe to approximate when you can submit the next one) without having > detailed knowledge of how expensive each individual query was project > to be. But that's a pretty narrow use case, and I'm not sure it > really justifies the overhead of instrumenting every query in this > way. Well, progress information is probably only going to be useful for long- running processes anyway, and then only when the admin is too bored and wonders what he can usefully cancel. So it seems import to figure out exactly when to turn this on and when not to without causing too much overhead elsewhere. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
