[HACKERS] SQL/PSM prototype is available
Hello, Now, you can test prototype or work on it. All details are on http://postgresql.interweb.cz/index.php/SQL/PSM . This version needs patched core files http://postgresql.interweb.cz/index.php/SQL/PSM#Patches_for_core You can find supported functionality on http://postgresql.interweb.cz/index.php/SQL/PSM#Supported_statements . Next week I should work on for and get diagnostic stmts implementation. There is a lot of work (please see ToDo and Errors sections). It's can be success if in you plpgpsm interpret will run. I plan take full functionality first and clean and refactorise source code later. Dificult part is exception handling :-(, because all postgresql stored rutines have to run under transaction, which standard doesn't expect. Please, use code from CVS. Best regards Pavel Stehule _ Emotikony a pozadi programu MSN Messenger ozivi vasi konverzaci. http://messenger.msn.cz/ ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
[HACKERS] todo list management
Hi, PostgreSQL 8.2 is out of the door. Unfortunately the plans for a more detailed todo list have not come into reality yet to assist in for the next 8.3 release. A couple people have replied to my earlier request to form a little team willing to work on this, but unfortunately people seem to have time constraints that prohibit them from working on this. I am still willing to spend time on being the person secretary of people, but I do not know enough about the internals of PostgreSQL to do this on my own, let alone start an initial list like I did for the PHP project. My goal is to for now cover the tricky long running todo's, document their progress, the people involved as well as any discussions and more importantly their conclusions. This should make it easier for other people to help on these todo's, or even take over if for some reason the original people do not have time to complete the todo themselves. This should also help people like Bruce, because they can get an idea about the progress without necessarily having to track down the people involved and it should also make the progress more transparent to end users. This is essentially what was started with the developers wiki already [1]. It seems the wiki is already seeing good use for the XML support and query progress indicator. Again, I am here and willing to help. I do not want to hassle this list with a lengthy thread, so hopefully the result will just be someone pushing me into the right directions. regards, Lukas [1] http://developer.postgresql.org/ ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] SQL/PSM prototype is available
On 12/17/06, Pavel Stehule [EMAIL PROTECTED] wrote: Now, you can test prototype or work on it. Cool. Good work Pavel. I'll play with it and some of my PSM code. I'll try and contact you via IM as to things I'd like to help with. -- Jonah H. Harris, Software Architect | phone: 732.331.1324 EnterpriseDB Corporation| fax: 732.331.1301 33 Wood Ave S, 3rd Floor| [EMAIL PROTECTED] Iselin, New Jersey 08830| http://www.enterprisedb.com/ ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] development environment of postgres
[EMAIL PROTECTED] (dakotali kasap) writes: I want to ask, which development environment should I use to add new features to postgresql. Is Eclipse CDT (C/C++ Development Tool) suitable for this, or are you using another environment, or just using pico, vi, etc.? I can't speak for you. I find my competence is maximized when I'm using Emacs; others find other sets of tools preferable. The code doesn't care what tool you're best with. - There are people who will swear by vi + ctags. - There are some who still use QED. (Albeit not for this project...) http://cm.bell-labs.com/cm/cs/who/dmr/qed.html (These would be extreme Unix partisans who think that the move from ed to vi was a Bad Thing... :-)) - Others prefer some form of Emacs. - One of my coworkers I think uses pico for most things; he's not keen on either of the typical Unix editors. As a quite wide-ranging rule, a worker who blames his tools for things not working tends to be *spectacularly* incompetent. If you pick tools you're not highly familiar with, you'll be liable to fall into that sort of problem :-(. Pick an editor you are intimately familiar with, and you'll be as well off as you can be. Your errors will be your own :-). -- let name=cbbrowne and tld=cbbrowne.com in String.concat @ [name;tld];; http://cbbrowne.com/info/sap.html `I am convinced that interactive systems will never displace batch systems for many applications.' - Brooks, _The Mythical Man-Month_ (And this does indeed seem true. MVS/CICS systems have *NOT* gone away...) ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] development environment of postgres
Chris Browne wrote: [EMAIL PROTECTED] (dakotali kasap) writes: I want to ask, which development environment should I use to add new features to postgresql. Is Eclipse CDT (C/C++ Development Tool) suitable for this, or are you using another environment, or just using pico, vi, etc.? I can't speak for you. I find my competence is maximized when I'm using Emacs; others find other sets of tools preferable. The code doesn't care what tool you're best with. - There are people who will swear by vi + ctags. - There are some who still use QED. (Albeit not for this project...) http://cm.bell-labs.com/cm/cs/who/dmr/qed.html (These would be extreme Unix partisans who think that the move from ed to vi was a Bad Thing... :-)) - Others prefer some form of Emacs. - One of my coworkers I think uses pico for most things; he's not keen on either of the typical Unix editors. Higher end IDEs tend to work best with some sort of project setup. If we were to support that it would be impossible - we'd forever have breakage. We support exactly the toolset needed to build postgres, and let you choose your own creation and management tools. There are plenty of emacs users among the hackers, and it's possible to set up emacs to drive building, debugging, the whole thing. For the most part I just use its editing facities, and drive everything else from the command line. cheers andrew ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] development environment of postgres
I am also usually working with a simple editor and command line, but because the postgresql project is too big for a person who is looking at the source code for the first time, I thought it will be simpler using a tool like CDT, because jumping directly to a function definition that he wants to look at is easy. Anyway, CDT's opening definition feature did not work for postgresql source. I do not know why. I just wanted to know if somebody had accomplished this. Regards, dakotali - Original Message From: Andrew Dunstan [EMAIL PROTECTED] To: Chris Browne [EMAIL PROTECTED] Cc: pgsql-hackers@postgresql.org Sent: Sunday, December 17, 2006 5:21:33 PM Subject: Re: [HACKERS] development environment of postgres Chris Browne wrote: [EMAIL PROTECTED] (dakotali kasap) writes: I want to ask, which development environment should I use to add new features to postgresql. Is Eclipse CDT (C/C++ Development Tool) suitable for this, or are you using another environment, or just using pico, vi, etc.? I can't speak for you. I find my competence is maximized when I'm using Emacs; others find other sets of tools preferable. The code doesn't care what tool you're best with. - There are people who will swear by vi + ctags. - There are some who still use QED. (Albeit not for this project...) http://cm.bell-labs.com/cm/cs/who/dmr/qed.html (These would be extreme Unix partisans who think that the move from ed to vi was a Bad Thing... :-)) - Others prefer some form of Emacs. - One of my coworkers I think uses pico for most things; he's not keen on either of the typical Unix editors. Higher end IDEs tend to work best with some sort of project setup. If we were to support that it would be impossible - we'd forever have breakage. We support exactly the toolset needed to build postgres, and let you choose your own creation and management tools. There are plenty of emacs users among the hackers, and it's possible to set up emacs to drive building, debugging, the whole thing. For the most part I just use its editing facities, and drive everything else from the command line. cheers andrew ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Re: [HACKERS] development environment of postgres
dakotali kasap [EMAIL PROTECTED] writes: --0-1517433147-1166375569=:82897 Content-Type: text/plain; charset=ascii Content-Transfer-Encoding: quoted-printable I am also usually working with a simple editor and command line, but becaus= e the postgresql project is too big for a person who is looking at the sour= ce code for the first time, I thought it will be simpler using a tool like = CDT, because jumping directly to a function definition that he wants to loo= k at is easy. That's an essential tool even for someone who knows the code well ... but you shouldn't think that there's only one way to do it. I like glimpse under emacs (easily finds references to symbols as well as their definitions; not specific to any one programming language). I think some other people use ctags. regards, tom lane ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [PATCHES] [HACKERS] psql commandline conninfo
Andrew Dunstan wrote: Bruce Momjian wrote: I assume this patch will still allow a database name with an equals sign, right? psql dbname='a=b' Yes. In fact, reading the code it looks like the quotes are not necessary in this case. OK, good to know. Does the patch need documentation too? Are we deprecating the psql options now duplicated by the new functionality, like host/port/username/password? -- Bruce Momjian [EMAIL PROTECTED] EnterpriseDBhttp://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [PATCHES] [HACKERS] psql commandline conninfo
Bruce Momjian [EMAIL PROTECTED] writes: OK, good to know. Does the patch need documentation too? Certainly. Are we deprecating the psql options now duplicated by the new functionality, like host/port/username/password? I'd vote not. This is just another way to do it. regards, tom lane ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [PATCHES] [HACKERS] psql commandline conninfo
Tom Lane wrote: Bruce Momjian [EMAIL PROTECTED] writes: OK, good to know. Does the patch need documentation too? Certainly. That's why I haven't committed it yet. I intend to put info in the psql manual as well as in the libpq reference. Are we deprecating the psql options now duplicated by the new functionality, like host/port/username/password? I'd vote not. This is just another way to do it. I entirely agree. It lets you do some nice things that aren't obvious now, like: psql 'service=foo sslmode=require' cheers andrew ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] Security leak with trigger functions?
Tom Lane wrote: Martijn van Oosterhout kleptog@svana.org writes: The trigger never runs as the owner of the table AIUI, only ever as the definer of the function or as session user. Yeah. This might itself be seen as a bug: I think you could make a reasonable case that the default behavior ought to be to run as the table owner (but still overridable if trigger function is SECURITY DEFINER, of course). In the current situation a table owner can use a trigger function as a trojan horse against anyone modifying the table. Is this true for on-select rules too? In that case, couldn't any user run his code as postmaster by creating an appropriate on-select rule and waiting until somebody/cron backups the database using pg_dump? Or is pg_dump smart enough to skip dumping tables with on-select rules? greetings, Florian Pflug ---(end of broadcast)--- TIP 1: 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
Re: [HACKERS] Security leak with trigger functions?
Florian G. Pflug [EMAIL PROTECTED] writes: Is this true for on-select rules too? In that case, couldn't any user run his code as postmaster by creating an appropriate on-select rule and waiting until somebody/cron backups the database using pg_dump? I don't see any issue for views' on-select rules; they wouldn't get executed during either dump or reload. It does seem like there are some other potential hazards once you start thinking this way: * Datatype I/O functions: the output function will be run as superuser during pg_dump, and the input function during restore. I think this is not an attack spot today because I/O functions can only be written in C, but we'd have to think about the consequences before allowing I/O functions in trusted P/L languages. (Perhaps arrange for I/O functions to be run as if setuid to their owner? Could be expensive...) * Functions associated with indexes would get run during restore: both the datatype-related index support functions, and any functions used in functional indexes. This might be OK because we require such functions to be immutable, but I do not think the link from immutable to can't write database is currently air-tight. * Functions in CHECK constraints (either table or domain constraints) would be executed during restores. There is not an immutability constraint for these currently, although arguably it'd be reasonable to require? * Trigger functions: not executed during pg_dump, nor during a full restore, but they *would* be executed during a data-only restore if you'd not used --disable-triggers. * ON INSERT rules: likewise, executed during data-only restores, possibly resulting in execution of user-defined functions. During restores, we normally set the userid to be the table owner while loading data into a particular table, which would mostly close these holes except that I think a function can revert the session authorization to be whatever the outermost user id is. Probably we need to tighten up the conditions under which a SET SESSION AUTHORIZATION can be reverted within a function. regards, tom lane ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] [COMMITTERS] pgsql: Put JST back into the default set of timezone abbreviations; was
Hi Tom-san. I'm sorry in a very late reaction... I can't talk a lot for the reasons of not specialist. However, Everything seems to be helped by your patches. It functions certainly now.:-) Thanks!! P.S) I supplied the windows package of Slony-I Ver 1.2.2 for the reasons the problem was clear. Occasionally, even if the explanation is required... Regards, Hiroshi Saito - Original Message - From: Tom Lane Log Message: --- Put JST back into the default set of timezone abbreviations; was removed in an unexplainable moment of brain fade. Tags: REL8_2_STABLE Modified Files: -- pgsql/src/timezone/tznames: Asia.txt (r1.2 - r1.2.2.1) (http://developer.postgresql.org/cvsweb.cgi/pgsql/src/timezone/tznames/Asia.txt.diff?r1=1.2r2=1.2.2.1) Default (r1.2 - r1.2.2.1) (http://developer.postgresql.org/cvsweb.cgi/pgsql/src/timezone/tznames/Default.diff?r1=1.2r2=1.2.2.1) ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] development environment of postgres
Hi, To modify postgres, i use kwrite... then make and make install that's all But i use this web site to navegate inside the postgres code, i found it very useful http://www.mcknight.de/pgsql-doxygen/cvshead/html/ (of course, this web site may be don't have the recent realease of postgres) On 12/17/06, Tom Lane [EMAIL PROTECTED] wrote: dakotali kasap [EMAIL PROTECTED] writes: --0-1517433147-1166375569=:82897 Content-Type: text/plain; charset=ascii Content-Transfer-Encoding: quoted-printable I am also usually working with a simple editor and command line, but becaus= e the postgresql project is too big for a person who is looking at the sour= ce code for the first time, I thought it will be simpler using a tool like = CDT, because jumping directly to a function definition that he wants to loo= k at is easy. That's an essential tool even for someone who knows the code well ... but you shouldn't think that there's only one way to do it. I like glimpse under emacs (easily finds references to symbols as well as their definitions; not specific to any one programming language). I think some other people use ctags. regards, tom lane ---(end of broadcast)--- TIP 6: explain analyze is your friend
[HACKERS] Dirty pages in freelist cause WAL stuck
Hello, I'm testing the recently changes of WAL entries for freezing-tuples. VACUUM FREEZE took more time. The cause seems to be flushing WAL buffers. Vacuuming processes free buffers into freelist. The buffers in freelist is preferentially used on next allocation of buffers. Then, if the buffer is dirty, the allocator must write it before reuse. However, there are few buffers in freelist typically, buffers made dirty recently are reused too soon -- The WAL entries for the dirty buffer has not been flushed yet, so the allocator flushes WAL, writes the buffer, and finally reuses it. One solution is always keeping some buffers in freelist. If there were N buffers in freelist, the necessity of WAL-flusing was reduced to 1/N, because all WAL entries are flushed when we do one of them. The attached patch is an experimental implementation of the above. Keeping 32 buffers seems to be enough when executed separately. With some background jobs, other numbers may be better. N | time | XLogWrite/XLogFlush ---+---+- 1 | 68.2s | 25.6% 8 | 57.4s | 10.8% 32 | 54.0s | 3.4% [initial data] $ pgbench -s 40 -i; # VACUUM FREEZE [test] # UPDATE accounts SET aid=aid WHERE random() 0.005; # checkpoint; # VACUUM FREEZE accounts; I cannot see the above problem in non-freeze vacuum. The number buffers in freelist increases on index-vacuuming phase. When the vacuum found seldom used buffers (refcount==0 and usage_count==0), they are added into freelist. So the WAL entries generated in index-vacuuming or heap-vacuuming phase are not so serious. However, entries for FREEZE are generated in heap-scanning phase, it is before index-vacuuming. Are there any better fixes? Comments welcome. Regards, --- ITAGAKI Takahiro NTT Open Source Software Center freelist_buffers.patch Description: Binary data ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
[HACKERS] Is there any limitation on the size of a mail?
Hello, Sorry for this noisy mail. If there is more appropriate address to send to, please tell me. I sent one mail about load-distributed checkpoint three times on the following dates as I couldn't see the mail on the ML: 2006/12/16 17:53 2006/12/18 9:07 2006/12/18 12:10 But none has appeared on pgsql-hackers ML yet. What's wrong? One thing I worry about is the size. The size of my mail is 42KB. It has only text and no attachment. Is there any limitation on size? I'm sending this as a test too. ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] Is there any limitation on the size of a mail?
Takayuki Tsunakawa [EMAIL PROTECTED] writes: But none has appeared on pgsql-hackers ML yet. What's wrong? One thing I worry about is the size. The size of my mail is 42KB. It has only text and no attachment. Is there any limitation on size? Yes. Consider gzip ... or if appropriate, post to pgsql-patches, which has a higher limit. regards, tom lane ---(end of broadcast)--- TIP 1: 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
Re: [HACKERS] Is there any limitation on the size of a mail?
Hello, Mr. Lane Takayuki Tsunakawa [EMAIL PROTECTED] writes: But none has appeared on pgsql-hackers ML yet. What's wrong? One thing I worry about is the size. The size of my mail is 42KB. It has only text and no attachment. Is there any limitation on size? Yes. Consider gzip ... or if appropriate, post to pgsql-patches, which has a higher limit. Thank you for your advice. I've just succeeded in sending my mail. 22KB has been accepted. ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
