Re: [HACKERS] Where to see the patch queue (was Re: [PATCHES] Patch for Postmaster
Hi *, I have submitted a patch which does exactly this. Somebody edited it and Bruce put it on the queue for 8.1. Now we both did the same work twice. This is a good example how a public accessible Bugtracker and TODO-List where one can claim things (or get assigned to some workitem) can save valuable time. Image someone likes to get in touch with the codebase by fixing some bugs first. To my understanding, there is no Bug Database for Postgres (correct me, if I am wrong). Where can this volunteer lookup Bugs? I don't want to restart the Bugzilla Discussion, since I personally don't have any preference which Trouble-Ticket System to use. But I think the idea of having one is worth considering. cheers, Matthias Am 25.02.2005 um 03:51 schrieb Bruce Momjian: Eric Crampton wrote: On Feb 24, 2005, at 5:38 PM, Tom Lane wrote: Eric Crampton [EMAIL PROTECTED] writes: I noticed in the TODO that there is an item requesting a function which returns the uptime of the postmaster. I've wanted that as well. So, I've added just such a thing: server_start_time(). This function returns the time when the postmaster was started; a simple now() - server_start_time() returns the uptime. Isn't there one of these in the patch queue already? There could be, but I didn't see one because perhaps I'm looking in the wrong place. I referenced the TODO list here: http://developer.postgresql.org/todo.php and I referenced the unapplied patches here: http://momjian.postgresql.org/cgi-bin/pgpatches Where should I be looking? Sure: http://momjian.postgresql.org/cgi-bin/pgpatches2 -- Bruce Momjian| http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org -- Matthias Schmidt Viehtriftstr. 49 67346 Speyer GERMANY Tel.: +49 6232 4867 Fax.: +49 6232 640089 ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] [pgsql-hackers] Allow GRANT/REVOKE permissions to be applied to all schema
Hi *, I will start implementing this stuff based on this syntax: GRANT SELECT ON ALL TABLES IN public TO phpuser; GRANT SELECT ON NEW TABLES IN public TO phpuser; so there are two seperate commands to use. is everybody fine with this aproach? cheers, Matthias PS.: Tom, shouldn't we mention the fact, that one can grant on views and sequences as well in the documentation? Am 29.01.2005 um 01:43 schrieb Tom Lane: Josh Berkus josh@agliodbs.com writes: GRANT SELECT ON ALL, NEW TABLES IN public TO phpuser; ... does both. Ah, I overlooked that part of your message. I think the above probably doesn't work in bison, but if not we could spell it like GRANT SELECT ON ALL AND NEW TABLES IN public TO phpuser; Or just make the user enter two commands for this case. Aside from syntactic simplicity, that might be a good idea anyway. The NEW TABLES case is *fundamentally* different from every other form of GRANT, in that it causes future actions. So it might be a wise idea from the standpoint of understandability to keep it as a separate command from the immediate-acting ALL TABLES. regards, tom lane ---(end of broadcast)--- TIP 8: explain analyze is your friend -- Matthias Schmidt Viehtriftstr. 49 67346 Speyer GERMANY Tel.: +49 6232 4867 Fax.: +49 6232 640089 ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [HACKERS] Allow GRANT/REVOKE permissions to be applied to all schema objects with one command
Hi Merlin, sorry - I replied to Tom PG hackers before I saw you last post. I think it is best to code the basic functionallity within the two new commands, and see how this works out. We can add your idea and others on top of it later on. what about that? cheers, Matthias -- Matthias Schmidt Viehtriftstr. 49 67346 Speyer GERMANY Tel.: +49 6232 4867 Fax.: +49 6232 640089 ---(end of broadcast)--- TIP 8: explain analyze is your friend
[HACKERS] Allow GRANT/REVOKE permissions to be applied to all schema objects with one command
Hi Tom + *, as I learned from severall posts this TODO splits into two distinct TODO's TODO1: Allow GRANT/REVOKE permissions to be applied to all schema objects with one command. TODO2: Assign Permissions to schemas wich get automatically inherited by objects created in the schema. my questions are: a) should we pursue both of them? b) how can a syntax for TODO1 look like? Anchored at 'GRANT ... ON SCHEMA' or 'GRANT ... ON objecttype' ? greetings, Matthias -- Matthias Schmidt Viehtriftstr. 49 67346 Speyer GERMANY Tel.: +49 6232 4867 Fax.: +49 6232 640089 ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Some things I like to pick from the TODO list ...
OK guys - i think I go for #3: Allow GRANT/REVOKE permissions to be applied to all schema objects with one cheers, Matthias Am 18.01.2005 um 20:47 schrieb Tom Lane: Matthias Schmidt [EMAIL PROTECTED] writes: These are the things I'm interested in: 1) Allow limits on per-db/user connections 2) Allow server log information to be output as INSERT statements 3) Allow GRANT/REVOKE permissions to be applied to all schema objects with one 4) Allow PREPARE of cursors what's free, what's apropriate for a newbee like me? I'd vote for #3 just because it'd be much the most useful --- we get requests for that every other day, it seems like. The others are far down the wish-list. It's also localized enough that I think a newbie could handle it. regards, tom lane -- Matthias Schmidt Viehtriftstr. 49 67346 Speyer GERMANY Tel.: +49 6232 4867 Fax.: +49 6232 640089 ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
[HACKERS] Some things I like to pick from the TODO list ...
Hi *, I have some cylcles left and like to pick up something from the TODO list. These are the things I'm interested in: 1) Allow limits on per-db/user connections 2) Allow server log information to be output as INSERT statements 3) Allow GRANT/REVOKE permissions to be applied to all schema objects with one 4) Allow PREPARE of cursors what's free, what's apropriate for a newbee like me? cheers, Matthias -- Matthias Schmidt Viehtriftstr. 49 67346 Speyer GERMANY Tel.: +49 6232 4867 Fax.: +49 6232 640089 ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] uptime() for postmaster
Hi Tom, Am 31.12.2004 um 20:18 schrieb Tom Lane: Matthias Schmidt [EMAIL PROTECTED] writes: a) is the name uptime() OK? Probably should use pg_uptime(), or something else starting with pg_. What about 'pg_starttime()' since it is not a period but a point-in-time? b) is the return-type 'Interval' OK? It might be better to return the actual postmaster start time (as timestamptz) and let the user do whatever arithmetic he wants. With an interval, there's immediately a question of interpretation --- what current timestamp did you use in the computation? I'm not dead set on this, but it feels cleaner. you're right. Let's go for timestamptz and let the users decide ... c) does it make sense (... fit in the scheme?) to place the code here: src/backend/utils/misc/uptime.c No. This sort of stuff should go into utils/adt/. I'd be inclined to drop the function into one of the existing timestamp-related files rather than make a whole new file just for it. Someplace near the now() function would make sense, for instance. yep - so the stuff goes to: utils/adt/timestamp.c, where now() and many other time-related functions are. d) Can I piggy-back on 'BackendParameters' to get postmasters start-time to the backends? AFAICS you have no other choice. regards, tom lane cheers, Matthias -- Matthias Schmidt Viehtriftstr. 49 67346 Speyer Tel.: +49 6232 4867 Fax.: +49 6232 640089 ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
[HACKERS] uptime() for postmaster
Hi Bruce, I started to work on the uptime() for the postmaster yesterday. A couple of questions: a) is the name uptime() OK? b) is the return-type 'Interval' OK? c) does it make sense (... fit in the scheme?) to place the code here: src/backend/utils/misc/uptime.c d) Can I piggy-back on 'BackendParameters' to get postmasters start-time to the backends? happy new year, Matthias -- Matthias Schmidt Viehtriftstr. 49 67346 Speyer Tel.: +49 6232 4867 Fax.: +49 6232 640089 ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] somebody working on: Prevent default re-use of sysids for dropped users and groups?
Hi Tom, after beeing offline because of a chrashed box, I able to mail again. I would like to volunteer for the uptime() function. Is that OK? cheers, Matthias Am 13.12.2004 um 03:31 schrieb Bruce Momjian: Matthias Schmidt wrote: Am 07.12.2004 um 19:24 schrieb Tom Lane: Matthias Schmidt [EMAIL PROTECTED] writes: By the way: Do you have an idea about a small or medium sized task from the TODO-List for a newbee, which gets me up to speed?(!Win32) A lot of the tasks listed under DATA TYPES are fairly self-contained problems ... but what draws your interest? I think most of the tasks that are on TODO are there either because they're hard problems, or because nobody was very interested in them. Unfortunately they are not marked as to which is which :-(. Make a list of things you find interesting, and we can tell you if they're very hard or already claimed. regards, tom lane Hi Tom, this is a list of things I'm interested in: 1) Allow administrators to safely terminate individual sessions Right now, SIGTERM will terminate a session, but it is treated as though the postmaster has paniced and shared memory might not be cleaned up properly. A new signal is needed for safe termination. This one seems hard. 2) Add a function that returns the 'uptime' of the postmaster Seems like a good starting point. 3) Have SHOW ALL and pg_settings show descriptions for server-side variables Also a good one for you. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 -- Matthias Schmidt Viehtriftstr. 49 67346 Speyer Tel.: +49 6232 4867 Fax.: +49 6232 640089 ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [HACKERS] somebody working on: Prevent default re-use of sysids for dropped users and groups?
Am 07.12.2004 um 19:24 schrieb Tom Lane: Matthias Schmidt [EMAIL PROTECTED] writes: By the way: Do you have an idea about a small or medium sized task from the TODO-List for a newbee, which gets me up to speed?(!Win32) A lot of the tasks listed under DATA TYPES are fairly self-contained problems ... but what draws your interest? I think most of the tasks that are on TODO are there either because they're hard problems, or because nobody was very interested in them. Unfortunately they are not marked as to which is which :-(. Make a list of things you find interesting, and we can tell you if they're very hard or already claimed. regards, tom lane Hi Tom, this is a list of things I'm interested in: 1) Allow administrators to safely terminate individual sessions Right now, SIGTERM will terminate a session, but it is treated as though the postmaster has paniced and shared memory might not be cleaned up properly. A new signal is needed for safe termination. 2) Add a function that returns the 'uptime' of the postmaster 3) Have SHOW ALL and pg_settings show descriptions for server-side variables to be honest I'm only looking for a particular task to get things started. cheers, Matthias -- Matthias Schmidt Viehtriftstr. 49 67346 Speyer Tel.: +49 6232 4867 Fax.: +49 6232 640089 ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] somebody working on: Prevent default re-use of sysids for dropped users and groups?
Am 06.12.2004 um 23:27 schrieb Tom Lane: schmidtm [EMAIL PROTECTED] writes: Do I get that right: the only reason to do max(sysid) or a user-supplied ID in CreateUser() (commands/user.c) is that we don't have the ability to get sequences over the *.BKI/initdb mechanism? No, that's not quite the direction of the problem. The real reason those facilities are there is so that you can deliberately create a user having a previously-used sysid. And the only reason why that is needed is that we don't have dependency tracking for references to users and groups. If you could be certain that there were no remaining references to a userid when it is dropped, there would be no need to be able to resurrect it. And that would mean that we could forget the whole sysid assignment mess and just use the regular OID generator to create unique IDs for users and groups. Using a shared sequence instead of max(sysid) would be merely an incremental improvement in the existing sysid assignment rules --- it wouldn't eliminate the entire kluge at one blow. So if Alvaro's thing works out, the shared-sequence problem becomes moot. Probably that's a good reason not to spend time on it just yet. regards, tom lane makes totally sense to me. Let's wait for Alvaro's stuff. By the way: Do you have an idea about a small or medium sized task from the TODO-List for a newbee, which gets me up to speed?(!Win32) The TODO-List is a good starting point, but I cannot figure out who works on what. cheers, Matthias -- Matthias Schmidt Viehtriftstr. 49 67346 Speyer Tel.: +49 6232 4867 Fax.: +49 6232 640089 ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
