Re: [HACKERS] Reusing Dead Tuples:
Tom Lane wrote: Janardhan <[EMAIL PROTECTED]> writes: Does it breaks any other things if all the index entries pointing the dead tuple are removed before reusing the dead tuple?. Possibly you could make that work, but I think you'll find the efficiency advantage you were chasing to be totally gone. The locking scheme is heavily biased against you, and the index AMs don't offer an API designed for efficient retail index-tuple deletion. Of course that just says that you're swimming against the tide of previous optimization efforts. But the thing you need to face up to is you are taking what had been background maintenance tasks (viz, VACUUM) and moving them into the foreground critical path. This *will* slow down your foreground applications. regards, tom lane today i could able to complete the patch and it is working only for b-tree. i have added a new method am_delete to the API and bt_delete to the B-tree index to delete a single entry. for the timebeing this works only with b-tree indexs. Regarding the complexity of deleting a tuple from b-tree , it is same or less then that of inserting a tuple into a B-tree( since delete does not require spliting the page). The approach is slightly different to that of lazy vacuum. lazy vacuum scan entire index table to delete the dead entries. here it search for the pariticilar entry similer to that of insert . here locking may not have much impact. It locks only single buffer to delete the index entry. Regarding the efficiency, if the entire Index table is in buffered then it does not require any additional IO , only extra CPU is required to delete entries in index table. I am using postgres in a application where is there is heavy updates for group of tables(small size), before inserting a single record in huge table. this entire thing constitue single transaction. currently as time goes on the transaction processing speed decreases till the database is vacuumed. Using this new patch i am hoping the trasaction processing time will remain constant irrespective of time. Only i need to do vaccum once i delete large number of entries from some of the tables. regards, jana
Re: [mail] Re: [HACKERS] Update on replication
The reason I favour a GBorg is that VA Linux (who own sourceforge) have yet to turn in a profit and so maylook to trim some of it's assets in order to improve profitability at some point in the future. I think it would be a bad move to shift everything to sourceforge, only to find that a year or more down the line the site dissappears/degrades to a level where it causes problems for the project, and loose the time we could have spent building up the reputation of GBorg. Al. - Original Message - From: "Neil Conway" <[EMAIL PROTECTED]> To: "Greg Copeland" <[EMAIL PROTECTED]> Cc: "Alvaro Herrera" <[EMAIL PROTECTED]>; "Marc G. Fournier" <[EMAIL PROTECTED]>; "Tatsuo Ishii" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>; "PostgresSQL Hackers Mailing List" <[EMAIL PROTECTED]> Sent: Wednesday, December 18, 2002 2:55 AM Subject: [mail] Re: [HACKERS] Update on replication > On Tue, 2002-12-17 at 21:33, Greg Copeland wrote: > > I do agree, GBorg needs MUCH higher visibility! > > I'm just curious: why do we need GBorg at all? Does it offer anything > that SourceForge, or a similar service does not offer? > > Especially given that (a) most other OSS projects don't have a site for > "related projects" (unless you count something like CPAN, which is > totally different) (b) GBorg is completely unknown to anyone outside the > PostgreSQL community and even to many people within it... > > Cheers, > > Neil > -- > Neil Conway <[EMAIL PROTECTED]> || PGP Key ID: DB3C29FC > > > > > ---(end of broadcast)--- > TIP 4: Don't 'kill -9' the postmaster > ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
[HACKERS] a problem in authority
Hi, all I have installed the Postgresql 7.3 . But I think something is wrong with authority. I have made the following operations: 1. I enter the psql and run 'alter user postgres with password 'postgres'' 2. I change the pg_hba.conf and set the auth_type from 'trust' to 'password' 3. Then I can not connect to server. I have test connect from local or connect from host, but it just return 'authority fail for user postgres'. I can connect to postgresql 7.23 successfully after above steps; Great thanks for any message. Josh
[HACKERS] SourceForge policy on http://sourceforge.net/tos/tos.php
> I'm just curious: why do we need GBorg at all? Does it offer anything > that SourceForge, or a similar service does not offer? SAY NO TO SOURCEFORGE ! Please find enclosed some extracts from licensing terms (http://sourceforge.net/tos/tos.php) : a) Acceptance of Terms "We reserve the right, at our discretion, to change, modify, add or remove portions of these terms periodically. Such modifications shall be effective immediately upon posting of the modified agreement to the website. Your continued use of the SourceForge.net website following the posting of changes to these terms and conditions will mean that you accept those changes." -> My point of view : SourceForge has an unlimited right to change the content of the TOS. A simpe post of the modified TOS is sufficient. For example, they may at any time charge access to their web site. b) Licensing of code "In each such case, the submitting user grants SourceForge.net the royalty-free, perpetual, irrevocable, non-exclusive and fully sublicensable right and license to use, reproduce, modify, adapt, publish, translate, create derivative works from, distribute, perform and display such Content (in whole or part) worldwide and/or to incorporate it in other works in any form, media, or technology now known or later developed, all subject to the terms of any applicable approved license." -> My point of view : More surprisingly, SourceForge owns all content posted on SourceForge. For legal reasons, SF licensing agreement is subject to the terms of any applicable approved license. But, the words *** or later development *** are thrilling. c) Termination "We may terminate a user's account in our absolute discretion and for any reason. We are especially likely to terminate for reasons that include, but are not limited to, the following: 1.) violation of these Terms; 2.) abuse of site resources or attempt to gain unauthorized entry to the site or site resources; 3.) use of Service in a manner inconsistent with the Purpose; 4.) a user's request for such termination; and 5.) requirement of applicable law, regulation, court or governing agency order. -> My point of view : As a consequence, SourceForge does not allow a user to unregister from SourceForge. I tried to unregister a project from SF, without success. Why? Because SF owns the (your) project rights. d) Incompatibility with local european laws This contract does not comply with the European laws : - SF may change the licensing terms at any time, without limitation of the future modified clauses. In the European Union, you cannot grant an ***unlimited right*** on your ***future and undefined*** work without a ***defined counterpart*** (example=a salary). - In French law, an author right is devided in two separate rights : the owner right and the moral right. Every author (or community of authors) owns a moral right on his/her work, even after the selling of rights. It has several consequences which I wron't bother you with (even in RedHat attitude = the renaming of a software is unmoral, bacause it makes you believe RedHat is the original author of PostgreSQL). e) SourceForge is a closed-source service SourceForge migrated (=rewrote) their database server-side code from PostgreSQL to Oracle, mainly for legal reasond. This new work gives them the ability to change licences. As a consequence, SF did not release their code for a year or so. SF can now be considered as a closed-source service. f) I would discourage anyone from registering on SourceForge. Any organization is meant to be created, to live ... and die. Microsoft, Oracle and SourceForge will probably die sooner or later. On the other hand, open-source project provider, like Savannah or better GBOrg, which are owned by non-profit organization or individuals releasing their source code under the GNU, will never die. This make a huge difference. Now, what if Microsoft purchased OSDN? What would be the consequences? Cheers, Jean-Michel ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] [JDBC] Conversion between UNICODE and LATIN1 is not supported
Andreas, This would be better addressed to the hackers list, and I am forwarding it on. Dave On Wed, 2002-12-18 at 07:39, Andreas Joseph Krogh wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Hi all! > I get the following error when trying to connect to a pg-7.3 database on > Solaris8 with the 7.3 JDBC-driver. > Here is my output on the Solaris box: > www=> select version(); > version > - --- > PostgreSQL 7.3 on sparc-sun-solaris2.8, compiled by GCC gcc (GCC) 3.2 > (1 row) > > www=> set client_encoding = 'UNICODE'; > ERROR: Conversion between UNICODE and LATIN1 is not supported > www=> > > > Here is the same commands on my Linux box: > andreak=# select version(); > version > - >-- > PostgreSQL 7.3 on i686-pc-linux-gnu, compiled by GCC gcc (GCC) 3.2 (Mandrake > Linux 9.0 3.2-1mdk) > (1 row) > > andreak=# set client_encoding = 'UNICODE'; > SET > andreak=# > > = > > Does anybody know why this doesn't work on Solaris8? They are both compiled > with "./configure --with-pam" and multibyte support is enabled as default in > 7.3. I can allways recompile the JDBC-drivers with "set client_encoding = > 'LATIN1'; show autocommit" in AbstractJdbc1Connection.java, but that seems > hacky. > > - -- > Andreas Joseph Krogh <[EMAIL PROTECTED]> > The difference between insanity and genius is measured by success > -BEGIN PGP SIGNATURE- > Version: GnuPG v1.0.7 (GNU/Linux) > > iD8DBQE+AGxvUopImDh2gfQRAoLbAJ9y9ZOZNS513zahIkPMDP5tJ1zSGACgj6Xo > lxVLkYwE/I/sxRRRNvRSZFo= > =FsMP > -END PGP SIGNATURE- > > > ---(end of broadcast)--- > TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED] -- Dave Cramer <[EMAIL PROTECTED]> Cramer Consulting ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] SourceForge policy on http://sourceforge.net/tos/tos.php
Jean-Michel POURE <[EMAIL PROTECTED]> writes: > a) Acceptance of Terms > > "We reserve the right, at our discretion, to change, modify, add or remove > portions of these terms periodically. Such modifications shall be effective > immediately upon posting of the modified agreement to the website. Your > continued use of the SourceForge.net website following the posting of changes > to these terms and conditions will mean that you accept those changes." > > -> My point of view : SourceForge has an unlimited right to change the content > of the TOS. A simpe post of the modified TOS is sufficient. For example, they > may at any time charge access to their web site. This is standard legalities. They are a corporate entity; if there is a gap that leaves them liable for someone else's actions, they have to either be able to update their TOS -- or they must stop providing the service. > b) Licensing of code > > "In each such case, the submitting user grants SourceForge.net the > royalty-free, perpetual, irrevocable, non-exclusive and fully sublicensable > right and license to use, reproduce, modify, adapt, publish, translate, > create derivative works from, distribute, perform and display such Content > (in whole or part) worldwide and/or to incorporate it in other works in any > form, media, or technology now known or later developed, all subject to the > terms of any applicable approved license." > > -> My point of view : More surprisingly, SourceForge owns all content posted > on SourceForge. For legal reasons, SF licensing agreement is subject to the > terms of any applicable approved license. But, the words *** or later > development *** are thrilling. That is simply their legal way of saying "You may only publish 'open source' software and content on SourceForge" -- which is made clear when you sign up for a new project anyway. If you want them to distribute your software over the Internet, why do you care if they later distribute it over Planetnet? (The "in any ... technology ... later developed" does not scare me.) You must choose which license to use; if you do not want to use any of the approved licenses, *then* you might not want to use SourceForge. > c) Termination > > "We may terminate a user's account in our absolute discretion and for any > reason. We are especially likely to terminate for reasons that include, but > are not limited to, the following: 1.) violation of these Terms; 2.) abuse of > site resources or attempt to gain unauthorized entry to the site or site > resources; 3.) use of Service in a manner inconsistent with the Purpose; 4.) > a user's request for such termination; and 5.) requirement of applicable law, > regulation, court or governing agency order. > > -> My point of view : As a consequence, SourceForge does not allow a user to > unregister from SourceForge. I tried to unregister a project from SF, without > success. Why? Because SF owns the (your) project rights. Your project has nothing to do with their ability to terminate accounts. When I tried to unregister a project from SF, it took months, but they eventually did it. Maybe it helped that we were just renaming the project to something else on SF and had already moved the CVS tree. > d) Incompatibility with local european laws > > This contract does not comply with the European laws : > > - SF may change the licensing terms at any time, without limitation of the > future modified clauses. In the European Union, you cannot grant an > ***unlimited right*** on your ***future and undefined*** work without a > ***defined counterpart*** (example=a salary). Where does it say SF may change the licensing terms? If you do not want them to change the licensing terms much, you can do something like using GPL instead of BSD. Neither do they claim any right at all on your future work, unless you send those works to them -- "Licensing of code" merely says that once you send them something, they have an unlimited right to use and redistribute it. > - In French law, an author right is devided in two separate rights : the owner > right and the moral right. Every author (or community of authors) owns a > moral right on his/her work, even after the selling of rights. It has several > consequences which I wron't bother you with (even in RedHat attitude = the > renaming of a software is unmoral, bacause it makes you believe RedHat is the > original author of PostgreSQL). This is partially a license issue, and partially an international law issue, but it has little bearing on whether one uses SourceForge or not; *any* user of the code can exercise the same rights. You say below that you prefer Savannah over SourceForge, but Savannah does little enough to acknowledge that their code is based on SourceForge's code. Why criticize RedHat for doing the same thing? > e) SourceForge is a closed-source service > > SourceForge migrated (=rewrote) their database server-side code from > PostgreSQ
[HACKERS] v7.3.1 tar ready ... please check it ...
Going to announce later this evening to give the mirrors a chance to catch up ... let me know if there are any problems .. ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] v7.3.1 tar ready ... please check it ...
Is this going to be announced to a wider press audience? Has anyone gone over the "list of things to do when we release" to make sure things like the websites getting updated or perhaps getting rpm builds coordinated has been done? Robert Treat On Wed, 2002-12-18 at 09:18, Marc G. Fournier wrote: > > Going to announce later this evening to give the mirrors a chance to catch > up ... let me know if there are any problems .. > ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] v7.3.1 tar ready ... please check it ...
On Wed, 18 Dec 2002, Robert Treat wrote: > Is this going to be announced to a wider press audience? Has anyone gone > over the "list of things to do when we release" to make sure things like > the websites getting updated or perhaps getting rpm builds coordinated > has been done? No, we don't do that with minor releases ... nothing has changed that needs to be announced, other then a few bugs fixed ... > > Robert Treat > > > On Wed, 2002-12-18 at 09:18, Marc G. Fournier wrote: > > > > Going to announce later this evening to give the mirrors a chance to catch > > up ... let me know if there are any problems .. > > > > > > ---(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] v7.3.1 tar ready ... please check it ...
On Wed, 2002-12-18 at 09:51, Marc G. Fournier wrote: > On Wed, 18 Dec 2002, Robert Treat wrote: > > > Is this going to be announced to a wider press audience? Has anyone gone > > over the "list of things to do when we release" to make sure things like > > the websites getting updated or perhaps getting rpm builds coordinated > > has been done? > > No, we don't do that with minor releases ... nothing has changed that > needs to be announced, other then a few bugs fixed ... > Surly the websites will still need to be updated, rpm's need to be built, things like that... Robert Treat ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] v7.3.1 tar ready ... please check it ...
On Wed, 18 Dec 2002, Robert Treat wrote: > On Wed, 2002-12-18 at 09:51, Marc G. Fournier wrote: > > On Wed, 18 Dec 2002, Robert Treat wrote: > > > > > Is this going to be announced to a wider press audience? Has anyone gone > > > over the "list of things to do when we release" to make sure things like > > > the websites getting updated or perhaps getting rpm builds coordinated > > > has been done? > > > > No, we don't do that with minor releases ... nothing has changed that > > needs to be announced, other then a few bugs fixed ... > > > > Surly the websites will still need to be updated, rpm's need to be > built, things like that... Of course, but that has nothing to do with announcing to a wider press audience ... :) ---(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
Re: [HACKERS] v7.3.1 tar ready ... please check it ...
On 18 Dec 2002 at 8:54, scott.marlowe wrote: > > www.linuxtoday.com has weekly updates from many gnu / OSS projects which > are far less interesting than our 7.3.1 release is. I could see posting a > minor upgrade release notice there and on other OSS news web site > (freshmeat, slashdot, etc...) I read linuxtoday and /. daily. Linuxtoday is OK but /. would be an almost waste of another 800 comments of postgresql v/s mysql. Just a thought.. Bye Shridhar -- Manly's Maxim: Logic is a systematic method of coming to the wrong conclusion with confidence. ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] v7.3.1 tar ready ... please check it ...
"Marc G. Fournier" <[EMAIL PROTECTED]> writes: > Going to announce later this evening to give the mirrors a chance to catch > up ... let me know if there are any problems .. Tarball looks good from here. regards, tom lane ---(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] v7.3.1 tar ready ... please check it ...
On Wed, 18 Dec 2002, Tom Lane wrote: > "Marc G. Fournier" <[EMAIL PROTECTED]> writes: > > Going to announce later this evening to give the mirrors a chance to catch > > up ... let me know if there are any problems .. > > Tarball looks good from here. Great, put out a short techy announcement this evening when I geth home ... ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
[HACKERS] create trigger on view
Greetings! Somewhere between 7.1 and 7.2, creating triggers on insert to a view has been disallowed. The docs still report it as a possibility -- see rules vs. triggers. Worse, we have a postgres database relying on this feature for several years now. What can I do? I suppose I could use a rule, but all the insert rule examples I can find in the docs have simple sql do instead clauses, whereas my trigger called a rather involved plsql function. Advice most appreciated. Take care, -- Camm Maguire[EMAIL PROTECTED] == "The earth is but one country, and mankind its citizens." -- Baha'u'llah ---(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
Re: [HACKERS] MySQL 4.1 Features
On Wed, 2002-12-18 at 01:49, Christopher Kings-Lynne wrote: > Looks like they've caught up on a lot of our features. I have to say I > appreciate them adding SERIAL as an alias for AUTO_INCREMENT. Perhaps we > should return the favour? :) Well, it's not the same as PostgreSQL's serial (which is a 32-bit NOT NULL incrementing integer -- MySQL's serial is a 64-bit unique, NOT NULL incrementing integer). Personally, I think the implementations are different enough that making AUTO_INCREMENT an alias for SERIAL on the PostgreSQL side of things would just confuse the situation further... Cheers, Neil -- Neil Conway <[EMAIL PROTECTED]> || PGP Key ID: DB3C29FC ---(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
[HACKERS] user defined settings (aka user defined guc variables)
I've been playing around with making it possible to create user defined guc variables. This has been discussed, at least in passing, before. And it is even anticipated in guc.c as a possible future feature: /* * Build the sorted array. This is split out so that it could be * re-executed after startup (eg, we could allow loadable modules to * add vars, and then we'd need to re-sort). */ It is a feature that would be nice to have, so that, for example, a user defined variable named "my_classpath" could be created to point to the java CLASSPATH needed by a custom C function. So far I have this much working: - A new backend function, pg_create_user_setting(name, value, islocal) is used to "register" the setting. - SHOW ALL, SHOW, current_setting(), and pg_show_all_settings()) will display it just like any other setting - Similarly, SET and set_config() will change it. I still need to make the user defined settings survive being saved by ALTER USER or ALTER DATABASE. I'm also thinking about a corresponding grammar addition, something along the lines of: CREATE SETTING name WITH VALUE value; This would effectively perform: SELECT pg_create_user_setting(name, value, false); I'm wondering whether it would be "a good thing" or "a bad thing" to have unrecognized settings found in postgresql.conf be registered as user defined settings? Any comments, concerns, or objections? Thanks, Joe ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] user defined settings (aka user defined guc variables)
On Wed, 18 Dec 2002, Joe Conway wrote: > I've been playing around with making it possible to create user defined guc > variables. This has been discussed, at least in passing, before. And it is > even anticipated in guc.c as a possible future feature: > /* > * Build the sorted array. This is split out so that it could be > * re-executed after startup (eg, we could allow loadable modules to > * add vars, and then we'd need to re-sort). > */ > > It is a feature that would be nice to have, so that, for example, a user > defined variable named "my_classpath" could be created to point to the java > CLASSPATH needed by a custom C function. Hmm. Is GUC really the best place for something like that? (not that there is any other place :-)). Gavin ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
[HACKERS] Fancy ADD COLUMN
Hi, Just letting people know that I've mostly stopped working on ADD COLUMN now. Basically it rapidly got way out of my league! Problems are: 1. Evaluating default for each row 2. Checking against check constraint 3. Checking against domain constraints 4. Whether or not it's considered an insert (I don't think it should be) 5. SERIAL rewriting I think it needs to be handled in the grammar/analyzer a lot (create table style). ie. A list of future actions is built up, etc. so it all gets passsed thru the normal channels. Anyway, it's a bit too hard for me, especially when I can only find an hour a week to do stuff! If anyone takes it on in the future, feel free to email me and I can back you up. I'll keep working on smaller, easily chewed chunks :P Cheers, Chris ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] a problem in authority
On Wed, 2002-12-18 at 09:20, postgresql wrote: > 2. I change the pg_hba.conf and set the auth_type from 'trust' to > 'password' > > 3. Then I can not connect to server. Try using 'md5' instead of 'password' in pg_hba.conf. -- Oliver Elphick <[EMAIL PROTECTED]> LFIX Limited ---(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] 7.3.1 stamped
On Tue, 17 Dec 2002, Nathan Mueller wrote: > > Well, we break backward compatibility so people can't use SSL2 to > > connect to the server. Backward compatibility to a broken protocol > > isn't what I would call secure. Is that accurate? > > I suppose. As long as the incompatibilty is mentioned in HISTORY I'm > fine. I read the SSL_CTX_new man page, and they recommend using SSLv23_method to provide backwards compatibility ... if someone doesn't wan tto use SSL2, they have the option to use TLS, but we shouldn't be forcigin them to use one or the othe r... I have made the change and am just building v7.3.1 right now ... should be available in a few minutes, and I'll announce it this evening as being available ... can you grab a copy and make sure that it works as expected? ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] v7.3.1 tar ready ... please check it ...
> -Original Message- > From: Marc G. Fournier [mailto:[EMAIL PROTECTED]] > Sent: 18 December 2002 14:51 > To: Robert Treat > Cc: [EMAIL PROTECTED] > Subject: Re: [HACKERS] v7.3.1 tar ready ... please check it ... > > > On Wed, 18 Dec 2002, Robert Treat wrote: > > > Is this going to be announced to a wider press audience? Has anyone > > gone over the "list of things to do when we release" to make sure > > things like the websites getting updated or perhaps getting > rpm builds > > coordinated has been done? > > No, we don't do that with minor releases ... nothing has > changed that needs to be announced, other then a few bugs fixed ... Maybe we should? The more publicity the better etc... Regards, Dave ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] v7.3.1 tar ready ... please check it ...
Shridhar Daithankar wrote: > On 18 Dec 2002 at 8:54, scott.marlowe wrote: > > > > www.linuxtoday.com has weekly updates from many gnu / OSS projects which > > are far less interesting than our 7.3.1 release is. I could see posting a > > minor upgrade release notice there and on other OSS news web site > > (freshmeat, slashdot, etc...) > > I read linuxtoday and /. daily. Linuxtoday is OK but /. would be an almost > waste of another 800 comments of postgresql v/s mysql. That's okay, another 800 comments of PostgreSQL vs MySQL on Slashdot would increase the load on Slashdot's MySQL server, thus making it slower and illustrating the point that they should be using PostgreSQL instead. [ ducks ] :-) -- Kevin Brown [EMAIL PROTECTED] ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
[HACKERS] COLUMN MODIFY
Hey guys, I was just thinking about altering column type. Now, I'm not actually going to implement it any time soon, but I'm just thinking about it!!! One proposal was to introduce a new pg_attribute column called 'attlognum' so changing a column would involve adding a new column, dropping the old one and nudging the attlognum so that the columns are still select *'d in the same order. That involves catalog changes, etc. My idea is why not do what cluster does? Can we just simply write an entire new relation with the new type, update relfilenode and drop the old relation? ISTM that that would prevent catalog changes and would occupy identical disk space (2 x table size) during the ALTER, but would automatically 'free' itself back down to 1 x table size. Otherwise, the user has to do a vacuum full. Actually, if the type is binary compatible with the old type, all you need to update is the catalog. The existing DROP COLUMN implementation could even be changed to work like that, so long as we just leave the attisdropped column always false. What do you think? Chris ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] user defined settings (aka user defined guc variables)
Joe Conway <[EMAIL PROTECTED]> writes: > I've been playing around with making it possible to create user defined guc > variables. This has been discussed, at least in passing, before. And it is > even anticipated in guc.c as a possible future feature: It's fairly clear how the mechanisms for this would work. What's less clear to me is what's the point? I do not see any reason to have a GUC variable that isn't defined and used by some chunk of low-level C code. regards, tom lane ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] user defined settings (aka user defined guc variables)
Tom Lane wrote: Joe Conway <[EMAIL PROTECTED]> writes: I've been playing around with making it possible to create user defined guc variables. This has been discussed, at least in passing, before. And it is even anticipated in guc.c as a possible future feature: It's fairly clear how the mechanisms for this would work. What's less clear to me is what's the point? I do not see any reason to have a GUC variable that isn't defined and used by some chunk of low-level C code. Well, the java example (CLASSPATH) I gave is one instance. The value could be accessed by C code in a user defined function. Another example is an application I have at work. It is designed as a single app that is configured and used in multiple physical locations. Eventually all the data are collected in one central instance of the app, and therefore each instance needs its own guid that is stamped on every record in the database. Currently we store the guid in a single row table that gets populated by the install script. Could we continue to do it this way -- sure. But it seems like a natural place to use a configuration setting. Another example I thought about was session information for a web app. Lots of people use fairly small tables with a high churn rate to do this. A user defined setting could be used to store these like persistent cookies without building up large numbers of dead tuples that need vacuuming all the time. I know all of these can be done in other ways. If there's no interest, I'll accept that this was a dumb idea and move on ;-) Joe ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] v7.3.1 tar ready ... please check it ...
On Wed, 18 Dec 2002, Dave Page wrote: > > > > -Original Message- > > From: Marc G. Fournier [mailto:[EMAIL PROTECTED]] > > Sent: 18 December 2002 14:51 > > To: Robert Treat > > Cc: [EMAIL PROTECTED] > > Subject: Re: [HACKERS] v7.3.1 tar ready ... please check it ... > > > > > > On Wed, 18 Dec 2002, Robert Treat wrote: > > > > > Is this going to be announced to a wider press audience? Has anyone > > > gone over the "list of things to do when we release" to make sure > > > things like the websites getting updated or perhaps getting > > rpm builds > > > coordinated has been done? > > > > No, we don't do that with minor releases ... nothing has > > changed that needs to be announced, other then a few bugs fixed ... > > Maybe we should? The more publicity the better etc... The problem is that there is nothing to announce ... "Hi, we fixed some bugs"? :) minor releases don't have any features added to them, so isn't really news worthy ... :( ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] v7.3.1 tar ready ... please check it ...
On Wed, 18 Dec 2002, Marc G. Fournier wrote: > On Wed, 18 Dec 2002, Dave Page wrote: > > > > > > > > -Original Message- > > > From: Marc G. Fournier [mailto:[EMAIL PROTECTED]] > > > Sent: 18 December 2002 14:51 > > > To: Robert Treat > > > Cc: [EMAIL PROTECTED] > > > Subject: Re: [HACKERS] v7.3.1 tar ready ... please check it ... > > > > > > > > > On Wed, 18 Dec 2002, Robert Treat wrote: > > > > > > > Is this going to be announced to a wider press audience? Has anyone > > > > gone over the "list of things to do when we release" to make sure > > > > things like the websites getting updated or perhaps getting > > > rpm builds > > > > coordinated has been done? > > > > > > No, we don't do that with minor releases ... nothing has > > > changed that needs to be announced, other then a few bugs fixed ... > > > > Maybe we should? The more publicity the better etc... > > The problem is that there is nothing to announce ... "Hi, we fixed some > bugs"? :) minor releases don't have any features added to them, so isn't > really news worthy ... :( > I think changing major version of libpq is an important thing to be mentioned. > ---(end of broadcast)--- > TIP 4: Don't 'kill -9' the postmaster > Regards, Oleg _ Oleg Bartunov, sci.researcher, hostmaster of AstroNet, Sternberg Astronomical Institute, Moscow University (Russia) Internet: [EMAIL PROTECTED], http://www.sai.msu.su/~megera/ phone: +007(095)939-16-83, +007(095)939-23-83 ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] v7.3.1 tar ready ... please check it ...
On Wed, 18 Dec 2002, Marc G. Fournier wrote: > The problem is that there is nothing to announce ... "Hi, we fixed some > bugs"? :) minor releases don't have any features added to them, so isn't > really news worthy ... :( I don't know, if you're a postgresql user and you don't read these lists, you might find out about a bug in a release note and upgrade when you otherwise might not. www.linuxtoday.com has weekly updates from many gnu / OSS projects which are far less interesting than our 7.3.1 release is. I could see posting a minor upgrade release notice there and on other OSS news web site (freshmeat, slashdot, etc...) ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] v7.3.1 tar ready ... please check it ...
On Wed, 18 Dec 2002, scott.marlowe wrote: > On Wed, 18 Dec 2002, Marc G. Fournier wrote: > > > The problem is that there is nothing to announce ... "Hi, we fixed some > > bugs"? :) minor releases don't have any features added to them, so isn't > > really news worthy ... :( > > I don't know, if you're a postgresql user and you don't read these lists, > you might find out about a bug in a release note and upgrade when you > otherwise might not. > > www.linuxtoday.com has weekly updates from many gnu / OSS projects which > are far less interesting than our 7.3.1 release is. I could see posting a > minor upgrade release notice there and on other OSS news web site > (freshmeat, slashdot, etc...) Okay, that I agree on ... note that my press list contains alot more then that, most of which wouldn't be appropriate for a minor release ... maybe we need to setup a seperate 'minor release' list? Please note, I have no problems sending it out to a bunch of email addresses, I'm just questioning whether it makes sense to do so ... freshmeat not withstanding, since I don't see it as much of an annoucne site as a centralized list of OSS software ... ---(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] v7.3.1 tar ready ... please check it ...
scott.marlowe wrote: On Wed, 18 Dec 2002, Marc G. Fournier wrote: The problem is that there is nothing to announce ... "Hi, we fixed some bugs"? :) minor releases don't have any features added to them, so isn't really news worthy ... :( I don't know, if you're a postgresql user and you don't read these lists, you might find out about a bug in a release note and upgrade when you otherwise might not. www.linuxtoday.com has weekly updates from many gnu / OSS projects which are far less interesting than our 7.3.1 release is. I could see posting a minor upgrade release notice there and on other OSS news web site (freshmeat, slashdot, etc...) At the very least the PostgreSQL website team should be loudly notified so we can confirm the needed links have been updated prior to the release announcement. It probably wouldn't hurt to go through a proper release process, but determine which steps are optional or not needed for smaller releases. :-) Regards and best wishes, Justin clift -- "My grandfather once told me that there are two kinds of people: those who work and those who take the credit. He told me to try to be in the first group; there was less competition there." - Indira Gandhi ---(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
Re: [HACKERS] v7.3.1 tar ready ... please check it ...
On Wed, 2002-12-18 at 08:53, Dave Page wrote: > > -Original Message- > > From: Marc G. Fournier [mailto:[EMAIL PROTECTED]] > > Sent: 18 December 2002 14:51 > > To: Robert Treat > > Cc: [EMAIL PROTECTED] > > Subject: Re: [HACKERS] v7.3.1 tar ready ... please check it ... > > > > > > On Wed, 18 Dec 2002, Robert Treat wrote: > > > > > Is this going to be announced to a wider press audience? Has anyone > > > gone over the "list of things to do when we release" to make sure > > > things like the websites getting updated or perhaps getting > > rpm builds > > > coordinated has been done? > > > > No, we don't do that with minor releases ... nothing has > > changed that needs to be announced, other then a few bugs fixed ... > > Maybe we should? The more publicity the better etc... > > Regards, Dave > > ---(end of broadcast)--- > TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED] I agree it should be considered. It helps build mind share, which I think we can all agree is somewhat lacking for PostgreSQL compared to MySQL. It helps build the impression that PostgreSQL doesn't just sit idle between major releases. It allows a potential user base to see "PostgreSQL" more frequently and build interest. It let's people know that PostgreSQL is constantly being improved. Mind share is a powerful thing and as any advertiser will tell you, press releases is one of the best ways to get the word out. Greg -- Greg Copeland <[EMAIL PROTECTED]> Copeland Computer Consulting ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] 7.3.1 stamped
> I have made the change and am just building v7.3.1 right now ... > should be > available in a few minutes, and I'll announce it this evening as being > available ... can you grab a copy and make sure that it works as > expected? It works fine for me. --Nate ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] v7.3.1 tar ready ... please check it ...
"Marc G. Fournier" <[EMAIL PROTECTED]> writes: > On Wed, 18 Dec 2002, Dave Page wrote: >> Maybe we should? The more publicity the better etc... > The problem is that there is nothing to announce ... "Hi, we fixed some > bugs"? :) minor releases don't have any features added to them, so isn't > really news worthy ... :( I think this is exactly the difference between "press release" and "technical announcement" that Marc was getting beat up on just a couple weeks ago. A bug-fix-only update is not worthy of a press release. It is worthy of a technical announcement --- which is exactly what Marc plans to push out to pgsql-announce as soon as the FTP mirrors are up to date. regards, tom lane ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] v7.3.1 tar ready ... please check it ...
> -Original Message- > From: Tom Lane [mailto:[EMAIL PROTECTED]] > Sent: 18 December 2002 16:34 > To: Marc G. Fournier > Cc: Dave Page; Robert Treat; [EMAIL PROTECTED] > Subject: Re: [HACKERS] v7.3.1 tar ready ... please check it ... > > > "Marc G. Fournier" <[EMAIL PROTECTED]> writes: > > On Wed, 18 Dec 2002, Dave Page wrote: > >> Maybe we should? The more publicity the better etc... > > > The problem is that there is nothing to announce ... "Hi, we fixed > > some bugs"? :) minor releases don't have any features > added to them, > > so isn't really news worthy ... :( > > I think this is exactly the difference between "press > release" and "technical announcement" that Marc was getting > beat up on just a couple weeks ago. A bug-fix-only update is > not worthy of a press release. It is worthy of a technical > announcement --- which is exactly what Marc plans to push out > to pgsql-announce as soon as the FTP mirrors are up to date. I think Marc got beat up over the fact that we (pgsql-*) got the press release, not the gory details, rather than whether or not we sent a press release to other sites. I would suggest: - pgsql-announce gets the tech version for every release. - Marc's full contacts list get the major version notices in press format with a link to the tech version. - Marc's smaller techy contacts list (freshmeat, /. etc.) get a small press release with a link to the tech version for minor releases as well. Regards, Dave ---(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
[HACKERS] Table Timemachine!
Guys, I've been asked by a colleague about methods to keep track of 'previous' contents of a table - i.e. changes made and a way of getting back to a previous state. Now, I know INSERT/UPDATE/DELETE triggers to maintain an accompanying table is a way to do this. But, I have a nagging feeling that somebody has at one point put together such a feature in a generic fashion... I thought there was a 'time machine' module in contrib! Searches through the mailing lists have not turned up any specific pointers. Aanyone else remember this, and remember where? Or am I misguided and deluded! Thanks, Lee. ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] v7.3.1 tar ready ... please check it ...
On Wed, 18 Dec 2002, Dave Page wrote: > - pgsql-announce gets the tech version for every release. > - Marc's full contacts list get the major version notices in press > format with a link to the tech version. > - Marc's smaller techy contacts list (freshmeat, /. etc.) get a small > press release with a link to the tech version for minor releases as > well. Which sounds cool to me ... now, freshmeat I have to go to and modify locally ... does anyone have a list of contact email(s) that are apropriate for 'the techy contacts list'? ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] [GENERAL] Table Timemachine!
Lee Kindness <[EMAIL PROTECTED]> writes: > I have a nagging feeling that somebody has at one point put together > such a feature in a generic fashion... I thought there was a 'time > machine' module in contrib! contrib/spi/timetravel.* I haven't ever tried it ... regards, tom lane ---(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] v7.3.1 tar ready ... please check it ...
Oleg Bartunov wrote: > > > > No, we don't do that with minor releases ... nothing has > > > > changed that needs to be announced, other then a few bugs fixed ... > > > > > > Maybe we should? The more publicity the better etc... > > > > The problem is that there is nothing to announce ... "Hi, we fixed some > > bugs"? :) minor releases don't have any features added to them, so isn't > > really news worthy ... :( > > > > I think changing major version of libpq is an important thing to be > mentioned. It is mentioned in the release notes text: Migration to version 7.3.1 A dump/restore is *not* required for those running 7.3. However, it should be noted that the main PostgreSQL interface library, libpq, has a new major version number for this release, which may require recompilation of client code in certain cases. -- 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 ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] 7.3.1 stamped
Marc G. Fournier wrote: > On Tue, 17 Dec 2002, Nathan Mueller wrote: > > > > Well, we break backward compatibility so people can't use SSL2 to > > > connect to the server. Backward compatibility to a broken protocol > > > isn't what I would call secure. Is that accurate? > > > > I suppose. As long as the incompatibilty is mentioned in HISTORY I'm > > fine. > > I read the SSL_CTX_new man page, and they recommend using SSLv23_method to > provide backwards compatibility ... if someone doesn't wan tto use SSL2, > they have the option to use TLS, but we shouldn't be forcigin them to use > one or the othe r... > > I have made the change and am just building v7.3.1 right now ... should be > available in a few minutes, and I'll announce it this evening as being > available ... can you grab a copy and make sure that it works as expected? OK, I see from your commit message: From the SSL_CTX_new man page: "SSLv23_method(void), SSLv23_server_method(void), SSLv23_client_method(void) A TLS/SSL connection established with these methods will understand the SSLv2, SSLv3, and TLSv1 protocol. A client will send out SSLv2 client hello messages and will indicate that it also understands SSLv3 and TLSv1. A server will understand SSLv2, SSLv3, and TLSv1 client hello messages. This is the best choice when compatibility is a concern." This will maintain backwards compatibility for those us that don't use TLS connections ... My question is whether it is safe to be making this change in a minor release? Does it work with 7.3 to 7.3.1 combinations? My other question is, if SSLv2 isn't secure, couldn't a client say they only support SSLv2, and hence break into the server? That was my original hesitancy, that and the fact Bear the SSL guy didn't want it. -- 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 ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] [JDBC] Conversion between UNICODE and LATIN1 is not supported
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Thursday 19 December 2002 08:37, you wrote:
> Andreas Joseph Krogh wrote:
> > -BEGIN PGP SIGNED MESSAGE-
> > Hash: SHA1
> >
> > Hi all!
> > I get the following error when trying to connect to a pg-7.3 database on
> > Solaris8 with the 7.3 JDBC-driver.
> > Here is my output on the Solaris box:
> > www=> select version();
> > version
> > - ---
> > PostgreSQL 7.3 on sparc-sun-solaris2.8, compiled by GCC gcc (GCC) 3.2
> > (1 row)
> >
> > www=> set client_encoding = 'UNICODE';
> > ERROR: Conversion between UNICODE and LATIN1 is not supported
>
> This is not JDBC interface, it is PSQL command line utility!
>
> The message most likely is due to your database being LATIN1 encoded and I
> must agree with PostgreSQL - Unicode cannot be converted to Latin1, not all
> of it.
>
> So, check the database encoding: "psql -l".
I'm sorry if I was unclear, I initially got the error using the JDBC-driver
which issues the commands:
java.sql.ResultSet acRset =
ExecSQL("set client_encoding = 'UNICODE'; show
autocommit");
//set encoding to be unicode
encoding = Encoding.getEncoding("UNICODE", null);
if (!acRset.next())
{
throw new PSQLException("postgresql.con.failed",
"failed getting
autocommit status");
}
in AbstractJdbc1Connection.openConnection()
I had to recompile the JDBC-drivers with the method changed to
"set client_encoding = 'LATIN1'", as my database is as you guessed created
with "createdb -E LATIN1 dbname"
Then I realised I could reproduse it from the psql cmd-line, and posted the
error I got from there. Sorry for the confusion.
But my question still stands, why does this work on Linux and not Solaris8?
The docs say PostgreSQL can convert to and from LATIN1<->UNICODE as long as
multibyte support is enabled, which it is default in 7.3.
- --
Andreas Joseph Krogh <[EMAIL PROTECTED]>
The difference between insanity and genius is measured by success
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.0.7 (GNU/Linux)
iD8DBQE+AXljUopImDh2gfQRAlnYAJkBD+9kBPH8ME0doqOPctHApgHLowCeKkxK
5m5GngiT8tW7gUAPPTRV9JI=
=Hosd
-END PGP SIGNATURE-
---(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] v7.3.1 tar ready ... please check it ...
Marc G. Fournier writes: > Going to announce later this evening to give the mirrors a chance to catch > up ... let me know if there are any problems .. Plenty... The release notes are missing at least one item and contain at least one factual mistake that needs to be fixed. The HISTORY file needs to be reformatted because the line breaks look pretty ugly. The list of supported platforms needs to be revised and all platforms that have not received a confirmation yet have to be moved to unsupported. The INSTALL file needs to be updated to get the list of supported platforms up-to-date and the references to 7.3 need to be changed to 7.3.1. A note about the SSL incompatibility needs to be added or a fix needs to be mentioned in the list of changes. Someone also wrote me that a translation file is stuck in the pgsql-patches queue. It would be good if we could get that one in as well. -- Peter Eisentraut [EMAIL PROTECTED] ---(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] v7.3.1 tar ready ... please check it ...
Bruce Momjian writes: >A dump/restore is *not* required for those running 7.3. However, it >should be noted that the main PostgreSQL interface library, libpq, has >a new major version number for this release, which may require >recompilation of client code in certain cases. s/certain/all/ -- Peter Eisentraut [EMAIL PROTECTED] ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] v7.3.1 tar ready ... please check it ...
Peter Eisentraut wrote: > Bruce Momjian writes: > > >A dump/restore is *not* required for those running 7.3. However, it > >should be noted that the main PostgreSQL interface library, libpq, has > >a new major version number for this release, which may require > >recompilation of client code in certain cases. > > s/certain/all/ I was unclear on that. If they install right over their existing pgsql/lib directory, the old libpq will still be there, so a recompile will not be required. -- 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 ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] 7.3.1 stamped
On Wed, 18 Dec 2002, Bruce Momjian wrote: > Marc G. Fournier wrote: > > On Tue, 17 Dec 2002, Nathan Mueller wrote: > > > > > > Well, we break backward compatibility so people can't use SSL2 to > > > > connect to the server. Backward compatibility to a broken protocol > > > > isn't what I would call secure. Is that accurate? > > > > > > I suppose. As long as the incompatibilty is mentioned in HISTORY I'm > > > fine. > > > > I read the SSL_CTX_new man page, and they recommend using SSLv23_method to > > provide backwards compatibility ... if someone doesn't wan tto use SSL2, > > they have the option to use TLS, but we shouldn't be forcigin them to use > > one or the othe r... > > > > I have made the change and am just building v7.3.1 right now ... should be > > available in a few minutes, and I'll announce it this evening as being > > available ... can you grab a copy and make sure that it works as expected? > > OK, I see from your commit message: > > From the SSL_CTX_new man page: > > "SSLv23_method(void), SSLv23_server_method(void), SSLv23_client_method(void) > > A TLS/SSL connection established with these methods will understand the SSLv2, > SSLv3, and TLSv1 protocol. A client will send out SSLv2 client hello messages > and will indicate that it also understands SSLv3 and TLSv1. A server will > understand SSLv2, SSLv3, and TLSv1 client hello messages. This is the best > choice when compatibility is a concern." > > This will maintain backwards compatibility for those us that don't use > TLS connections ... > > My question is whether it is safe to be making this change in a minor > release? Does it work with 7.3 to 7.3.1 combinations? My other > question is, if SSLv2 isn't secure, couldn't a client say they only > support SSLv2, and hence break into the server? That was my original > hesitancy, that and the fact Bear the SSL guy didn't want it. Wow, which part of "A TLS/SSL connection established with these methods will understand the SSLv2, SSLv3, and TLSv1 protocol" are you finiding particularly confusing? As nate explained to you, and the man page section I commited states, TLSv1_method *only* supports TLS connections ... SSLv23_method supports SSLv2, v3 and TLSv1 ... As for 'break into the server" ... ummm ... isn't that what pg_hba.conf is for? I don't know about servers you run, but I don't let just anyone connect to my server, and, in fact, close down the databases themsleves to specific users ... if you don't trust the client, why are you giving him accss to your data, regardless of the protocol being used to encrypt the sessino?? ---(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
Re: [HACKERS] 7.3.1 stamped
Marc G. Fournier wrote: > > My question is whether it is safe to be making this change in a minor > > release? Does it work with 7.3 to 7.3.1 combinations? My other > > question is, if SSLv2 isn't secure, couldn't a client say they only > > support SSLv2, and hence break into the server? That was my original > > hesitancy, that and the fact Bear the SSL guy didn't want it. > > Wow, which part of "A TLS/SSL connection established with these methods > will understand the SSLv2, SSLv3, and TLSv1 protocol" are you finiding > particularly confusing? As nate explained to you, and the man page > section I commited states, TLSv1_method *only* supports TLS connections > ... SSLv23_method supports SSLv2, v3 and TLSv1 ... > > As for 'break into the server" ... ummm ... isn't that what pg_hba.conf is > for? I don't know about servers you run, but I don't let just anyone > connect to my server, and, in fact, close down the databases themsleves to > specific users ... if you don't trust the client, why are you giving him > accss to your data, regardless of the protocol being used to encrypt the > sessino?? I wasn't sure how insecure SSL2 was, and whether it allowed you to authenticate without a password or something. -- 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 ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] v7.3.1 tar ready ... please check it ...
Peter Eisentraut wrote: > Marc G. Fournier writes: > > > Going to announce later this evening to give the mirrors a chance to catch > > up ... let me know if there are any problems .. > > Plenty... > > The release notes are missing at least one item and contain at least one > factual mistake that needs to be fixed. The HISTORY file needs to be > reformatted because the line breaks look pretty ugly. The list of How do you do that? Do you manually reformat the whole file after you generate it, or do you just cut-paste the new release info into /HISTORY so the old manual formatting remains? It did line break badly. > supported platforms needs to be revised and all platforms that have not > received a confirmation yet have to be moved to unsupported. The INSTALL Do we do that during the first minor? I can do that if this is the time. > file needs to be updated to get the list of supported platforms up-to-date > and the references to 7.3 need to be changed to 7.3.1. A note about the Marc applied the patch after I stamped it. Marc, do you want me to do it? > SSL incompatibility needs to be added or a fix needs to be mentioned in > the list of changes. Someone also wrote me that a translation file is > stuck in the pgsql-patches queue. It would be good if we could get that > one in as well. -- 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 ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] v7.3.1 tar ready ... please check it ...
If it's all, perhaps we should reword as: ... has a new major version number for this release and will require recompilation of client code. Robert Treat On Wed, 2002-12-18 at 14:59, Peter Eisentraut wrote: > Bruce Momjian writes: > > >A dump/restore is *not* required for those running 7.3. However, it > >should be noted that the main PostgreSQL interface library, libpq, has > >a new major version number for this release, which may require > >recompilation of client code in certain cases. > > s/certain/all/ > ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] 7.3.1 stamped
On Wed, 18 Dec 2002, Marc G. Fournier wrote: > On Wed, 18 Dec 2002, Bruce Momjian wrote: > > > OK, I see from your commit message: > > > > From the SSL_CTX_new man page: > > > > "SSLv23_method(void), SSLv23_server_method(void), SSLv23_client_method(void) > > > > A TLS/SSL connection established with these methods will understand the SSLv2, > > SSLv3, and TLSv1 protocol. A client will send out SSLv2 client hello messages > > and will indicate that it also understands SSLv3 and TLSv1. A server will > > understand SSLv2, SSLv3, and TLSv1 client hello messages. This is the best > > choice when compatibility is a concern." > > > > This will maintain backwards compatibility for those us that don't use > > TLS connections ... > > > > My question is whether it is safe to be making this change in a minor > > release? Does it work with 7.3 to 7.3.1 combinations? My other > > question is, if SSLv2 isn't secure, couldn't a client say they only > > support SSLv2, and hence break into the server? That was my original > > hesitancy, that and the fact Bear the SSL guy didn't want it. > > Wow, which part of "A TLS/SSL connection established with these methods > will understand the SSLv2, SSLv3, and TLSv1 protocol" are you finiding > particularly confusing? As nate explained to you, and the man page > section I commited states, TLSv1_method *only* supports TLS connections > ... SSLv23_method supports SSLv2, v3 and TLSv1 ... > > As for 'break into the server" ... ummm ... isn't that what pg_hba.conf is > for? I don't know about servers you run, but I don't let just anyone > connect to my server, and, in fact, close down the databases themsleves to > specific users ... if you don't trust the client, why are you giving him > accss to your data, regardless of the protocol being used to encrypt the > sessino?? But, insecure SSL allows for "man in the middle" type of attacks. I.e. someone can sniff your secure (?) connection and get the password out of it, then spoof your IP and get in. The REASON for including TLS/SSL was to give people the ability to connect in a secure method so that IF someone is trying to listen in, they can't grab your name/password or your data. Allowing SSL connects means that that could happen. Disallowing them inconveniences the user. My suggestion would be to implement another GUC that by default turns off the insecure connections, and has to be uncommented and changed by the dba to allow the server to serve the insecure SSL method. Best of both worlds. ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] FW: Duplicate oids!
Patrick Macdonald wrote: > > Tom Lane wrote: > > > > Alvaro Herrera <[EMAIL PROTECTED]> writes: > > > On Fri, Dec 13, 2002 at 09:43:19AM -0500, Tom Lane wrote: > > >> Actually, if you don't mind grabbing a copy of pg_filedump --- see > > >> http://sources.redhat.com/rhdb/tools.html > > > > > Has this been updated for 7.3? Last time I looked it only did 7.2, and > > > the site shows an old date. If it hasn't, are there plans to update it > > > sometime soon? It would be very useful to me right now... > > > > AFAIK it has not been updated yet. Patrick, do you have any near-term > > plans to do so? If not, perhaps Alvaro would like to do the legwork ;-) > > Yes, it's on my list of things to do. Look for an updated version > by middle of the week (once all the RHDB 2.1 work is finished). I've updated the pg_filedump utility for PostgreSQL 7.3. The new version, 1.1, requires a PostgreSQL 7.3 source tree to build and can be used against RHDB 2.x/1.x and PostgreSQL 7.3/7.2/7.1 installations. All questions and comments about the tool should be directed to [EMAIL PROTECTED], not this list. The pg_filedump utility can be found at the Red Hat Database Project site (http://sources.redhat.com/rhdb). Cheers, Patrick ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] v7.3.1 tar ready ... please check it ...
On Wed, 18 Dec 2002, Bruce Momjian wrote: > > file needs to be updated to get the list of supported platforms up-to-date > > and the references to 7.3 need to be changed to 7.3.1. A note about the > > Marc applied the patch after I stamped it. Marc, do you want me to do it? Just curious as to whether any of this is critical enough to force a rebuild of the .tar.gz files, or can they wait until v7.3.2? That is my only concern ... we can do it, and I can do the announce in the morning instead of this evening, just want to make sure that its critical enough ... ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] v7.3.1 tar ready ... please check it ...
Marc G. Fournier wrote: > On Wed, 18 Dec 2002, Bruce Momjian wrote: > > > > file needs to be updated to get the list of supported platforms up-to-date > > > and the references to 7.3 need to be changed to 7.3.1. A note about the > > > > Marc applied the patch after I stamped it. Marc, do you want me to do it? > > Just curious as to whether any of this is critical enough to force a > rebuild of the .tar.gz files, or can they wait until v7.3.2? That is my > only concern ... we can do it, and I can do the announce in the morning > instead of this evening, just want to make sure that its critical enough > ... Not sure. The tarball has 7.3 mentioned in the INSTALL file, not 7.3.1. I only today saw how to update that, and I have added it to my checklist. I think the port changes can wait for 7.3.2. I don't think the SSL change is critical to be mentioned because it only opens up something that was disabled in 7.3. -- 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 ---(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] 7.3.1 stamped
> > Wow, which part of "A TLS/SSL connection established with these methods > > will understand the SSLv2, SSLv3, and TLSv1 protocol" are you finiding > > particularly confusing? As nate explained to you, and the man page > > section I commited states, TLSv1_method *only* supports TLS connections > > ... SSLv23_method supports SSLv2, v3 and TLSv1 ... > > > > As for 'break into the server" ... ummm ... isn't that what pg_hba.conf is > > for? I don't know about servers you run, but I don't let just anyone > > connect to my server, and, in fact, close down the databases themsleves to > > specific users ... if you don't trust the client, why are you giving him > > accss to your data, regardless of the protocol being used to encrypt the > > sessino?? > > But, insecure SSL allows for "man in the middle" type of attacks. I.e. > someone can sniff your secure (?) connection and get the password out of > it, then spoof your IP and get in. The REASON for including TLS/SSL was > to give people the ability to connect in a secure method so that IF > someone is trying to listen in, they can't grab your name/password or > your data. > > Allowing SSL connects means that that could happen. Disallowing them > inconveniences the user. My suggestion would be to implement another GUC > that by default turns off the insecure connections, and has to be > uncommented and changed by the dba to allow the server to serve the > insecure SSL method. Best of both worlds. At this point, all the SSL2 problems are conjecture on my part, which I don't understand. I hesitate to do anything until someone really knowledgeable can comment. Re-enabling SSL2 as part of 7.3.1 makes sense until we can get a definative answer on the risks involved. -- 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 ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] 7.3.1 stamped
On Wed, 18 Dec 2002, Bruce Momjian wrote: > Marc G. Fournier wrote: > > > My question is whether it is safe to be making this change in a minor > > > release? Does it work with 7.3 to 7.3.1 combinations? My other > > > question is, if SSLv2 isn't secure, couldn't a client say they only > > > support SSLv2, and hence break into the server? That was my original > > > hesitancy, that and the fact Bear the SSL guy didn't want it. > > > > Wow, which part of "A TLS/SSL connection established with these methods > > will understand the SSLv2, SSLv3, and TLSv1 protocol" are you finiding > > particularly confusing? As nate explained to you, and the man page > > section I commited states, TLSv1_method *only* supports TLS connections > > ... SSLv23_method supports SSLv2, v3 and TLSv1 ... > > > > As for 'break into the server" ... ummm ... isn't that what pg_hba.conf is > > for? I don't know about servers you run, but I don't let just anyone > > connect to my server, and, in fact, close down the databases themsleves to > > specific users ... if you don't trust the client, why are you giving him > > accss to your data, regardless of the protocol being used to encrypt the > > sessino?? > > I wasn't sure how insecure SSL2 was, and whether it allowed you to > authenticate without a password or something. SSL2 seems to get a lot of votes for being broken in ways that cannot be fixed because they aren't simple buffer overflows. see: http://www.lne.com/ericm/papers/ssl_servers.html#1.2 My suggestion would be to eventually phase out ssl2 in favor of ssl3 or tls. And, as we are phasing it out, make it an opt-in thing, where the dba has to turn on ssl2 KNOWING he is turning on a flawed protocol. ---(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] v7.3.1 tar ready ... please check it ...
On Wed, 18 Dec 2002, Bruce Momjian wrote: > Peter Eisentraut wrote: > > Bruce Momjian writes: > > > > >A dump/restore is *not* required for those running 7.3. However, it > > >should be noted that the main PostgreSQL interface library, libpq, has > > >a new major version number for this release, which may require > > >recompilation of client code in certain cases. > > > > s/certain/all/ > > I was unclear on that. If they install right over their existing > pgsql/lib directory, the old libpq will still be there, so a recompile > will not be required. > It's not always safe to install over existing previous installation. I think special mention about recompiling DBD::Pg would be important > Regards, Oleg _ Oleg Bartunov, sci.researcher, hostmaster of AstroNet, Sternberg Astronomical Institute, Moscow University (Russia) Internet: [EMAIL PROTECTED], http://www.sai.msu.su/~megera/ phone: +007(095)939-16-83, +007(095)939-23-83 ---(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
Re: [HACKERS] 7.3.1 stamped
> At this point, all the SSL2 problems are conjecture on my part, which > I > don't understand. I hesitate to do anything until someone really > knowledgeable can comment. Re-enabling SSL2 as part of 7.3.1 makes > sense until we can get a definative answer on the risks involved. I'm not an expert, but as far as I know the only real differences between SSLv2 and v3 (which isn't different from TLSv1 from a security standpoint) are some things to prevent some man in the middle attacks. Thing is, most man in the middle attacks aren't that advanced. The attacker will intercept your attempt to connect to the server, do a handshake with you, do a handshake with the server and just sit in between. The only way (that I know of) to defend against this is to use certified public keys and I don't know of a way to do that with postgres. In short, I wouldn't call SSLv2 insecure, just less secure then v3. I think it's perfectly reasonable to phase it out, just not right now. It'd be nice to have some sort of transition version so you wouldn't have to switch over all your different client programs at the same time you switch all the servers. My preference would be for backwords compatibility in 7.3 and then eliminate it or provide a compile time option in 7.4. If the client stays with TLSv1 newer clients will only use the more secure protocols and older clients will still have the same problems they did before. I don't think that's too much of a problem. --Nate ---(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] v7.3.1 tar ready ... please check it ...
Oleg Bartunov wrote: > On Wed, 18 Dec 2002, Bruce Momjian wrote: > > > Peter Eisentraut wrote: > > > Bruce Momjian writes: > > > > > > >A dump/restore is *not* required for those running 7.3. However, it > > > >should be noted that the main PostgreSQL interface library, libpq, has > > > >a new major version number for this release, which may require > > > >recompilation of client code in certain cases. > > > > > > s/certain/all/ > > > > I was unclear on that. If they install right over their existing > > pgsql/lib directory, the old libpq will still be there, so a recompile > > will not be required. > > > > It's not always safe to install over existing previous installation. Uh, that's what we recommend right now. How is it wrong? > I think special mention about recompiling DBD::Pg would be important Uh, we don't distribute DBD:Pg. -- 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 ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] 7.3.1 stamped
scott.marlowe wrote: > > I wasn't sure how insecure SSL2 was, and whether it allowed you to > > authenticate without a password or something. > > SSL2 seems to get a lot of votes for being broken in ways that cannot be > fixed because they aren't simple buffer overflows. see: > > http://www.lne.com/ericm/papers/ssl_servers.html#1.2 > > My suggestion would be to eventually phase out ssl2 in favor of ssl3 or > tls. And, as we are phasing it out, make it an opt-in thing, where the > dba has to turn on ssl2 KNOWING he is turning on a flawed protocol. That was sort of my point --- if we allow SSLv2 in the server, are we open to any security problems? Maybe not. I just don't know. -- 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 ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] 7.3.1 stamped
Bruce Momjian writes: > I have prepared the 7.3 CVS branch in preparation of a 7.3.1 release > soon. Please check it. It would be of advantage if it were announced to the development group ahead of time when a minor release is planned, so work can be planned better. It is certainly extremely clumsy if the so-called release already sits on the FTP server while some of us are stilling trying to fix things up. -- Peter Eisentraut [EMAIL PROTECTED] ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] v7.3.1 tar ready ... please check it ...
Bruce Momjian writes: > I was unclear on that. If they install right over their existing > pgsql/lib directory, the old libpq will still be there, so a recompile > will not be required. That's kind of like saying, if you keep using PostgreSQL 7.2 then a dump/restore will not be required. ;-) Installing new code directly over old one without deleting is an extremely bad strategy. -- Peter Eisentraut [EMAIL PROTECTED] ---(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
Re: [HACKERS] v7.3.1 tar ready ... please check it ...
Bruce Momjian writes: > How do you do that? Do you manually reformat the whole file after you > generate it, or do you just cut-paste the new release info into > /HISTORY so the old manual formatting remains? It did line break badly. I put in the changes I had in mind and reformatted it, so as far as I'm concerned it's good to go now. -- Peter Eisentraut [EMAIL PROTECTED] ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] v7.3.1 tar ready ... please check it ...
Marc G. Fournier writes: > Just curious as to whether any of this is critical enough to force a > rebuild of the .tar.gz files, or can they wait until v7.3.2? That is my > only concern ... we can do it, and I can do the announce in the morning > instead of this evening, just want to make sure that its critical enough > ... Well the changes are mostly about elimating incorrect information from the release notes, which is surely critical, and putting in the correct version number, which is also critical. And neither of these things can wait for 7.3.2, because that would kind of defeat the point. If you jump the gun with building the tarballs that's the price you have to pay. -- Peter Eisentraut [EMAIL PROTECTED] ---(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] v7.3.1 tar ready ... please check it ...
Peter Eisentraut wrote: > Bruce Momjian writes: > > > I was unclear on that. If they install right over their existing > > pgsql/lib directory, the old libpq will still be there, so a recompile > > will not be required. > > That's kind of like saying, if you keep using PostgreSQL 7.2 then a > dump/restore will not be required. ;-) Installing new code directly over > old one without deleting is an extremely bad strategy. Well, our release notes say: A dump/restore is *not* required for those running 7.3. and INSTALL says: 4. Installing The Files Note: If you are upgrading an existing system and are going to install the new files over the old ones, then you should have backed up your data and shut down the old server by now, as explained in the Section called If You Are Upgrading above. In fact, we are a unclear about exactly when you need a dump/reload and when you don't. Seems the INSTALL file should have a clearer setup for folks upgrading from 7.3 to 7.3.1. -- 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 ---(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
Re: [HACKERS] 7.3.1 documentation updates
Bruce Momjian writes: > I have not been aggressive about backpatching documentation improvements > into 7.3.1. Is that something I should check? Probably in the future it would be good to put a minimal amount of work in polishing the documentation in the stable branch. > As I remember, we didn't update the official docs for minor releases. > Is that still true? It never was. -- Peter Eisentraut [EMAIL PROTECTED] ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] 7.3.1 documentation updates
Peter Eisentraut wrote: > Bruce Momjian writes: > > > I have not been aggressive about backpatching documentation improvements > > into 7.3.1. Is that something I should check? > > Probably in the future it would be good to put a minimal amount of work > in polishing the documentation in the stable branch. > > > As I remember, we didn't update the official docs for minor releases. > > Is that still true? > > It never was. I meant we don't create new doc tarballs for minor releases. Is that still true? -- 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 ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] 7.3.1 documentation updates
Bruce Momjian <[EMAIL PROTECTED]> writes: > I meant we don't create new doc tarballs for minor releases. Is that > still true? If someone's willing to do the work of regenerating the doc tarballs, I think it would be a real good idea to update them for minor releases. Peter, are you volunteering for that? I will take the blame for the lack of advance notice of this release. core had discussed it over the weekend, and agreed at my suggestion to plan a Wednesday release. We should have let -hackers know of the plan, and in fact I intended to do that but forgot. Mea culpa. regards, tom lane ---(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
Re: [HACKERS] user defined settings (aka user defined guc variables)
What exactly can you do with these variables other than SHOW/SET. Seems it would be nice if they could be used in queries, like in a special table like sysvar: SELECT sysvar.fsync; --- Joe Conway wrote: > I've been playing around with making it possible to create user defined guc > variables. This has been discussed, at least in passing, before. And it is > even anticipated in guc.c as a possible future feature: > /* > * Build the sorted array. This is split out so that it could be > * re-executed after startup (eg, we could allow loadable modules to > * add vars, and then we'd need to re-sort). > */ > > It is a feature that would be nice to have, so that, for example, a user > defined variable named "my_classpath" could be created to point to the java > CLASSPATH needed by a custom C function. > > So far I have this much working: > - A new backend function, pg_create_user_setting(name, value, islocal) is used >to "register" the setting. > - SHOW ALL, SHOW, current_setting(), and pg_show_all_settings()) will display >it just like any other setting > - Similarly, SET and set_config() will change it. > > I still need to make the user defined settings survive being saved by ALTER > USER or ALTER DATABASE. I'm also thinking about a corresponding grammar > addition, something along the lines of: > >CREATE SETTING name WITH VALUE value; > > This would effectively perform: >SELECT pg_create_user_setting(name, value, false); > > I'm wondering whether it would be "a good thing" or "a bad thing" to have > unrecognized settings found in postgresql.conf be registered as user defined > settings? > > Any comments, concerns, or objections? > > Thanks, > > Joe > > > ---(end of broadcast)--- > TIP 4: Don't 'kill -9' the postmaster > -- 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 ---(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
Re: [HACKERS] user defined settings (aka user defined guc variables)
- Original Message - From: "Gavin Sherry" <[EMAIL PROTECTED]> To: "Joe Conway" <[EMAIL PROTECTED]> > On Wed, 18 Dec 2002, Joe Conway wrote: > > > I've been playing around with making it possible to create user defined guc > > variables. This has been discussed, at least in passing, before. And it is > > even anticipated in guc.c as a possible future feature: > > /* > > * Build the sorted array. This is split out so that it could be > > * re-executed after startup (eg, we could allow loadable modules to > > * add vars, and then we'd need to re-sort). > > */ > > > > It is a feature that would be nice to have, so that, for example, a user > > defined variable named "my_classpath" could be created to point to the java > > CLASSPATH needed by a custom C function. > > Hmm. Is GUC really the best place for something like that? (not that there > is any other place :-)). > > Gavin Maybe GUC should be stored in a Berkeley DB? ;-) Mike Mascari [EMAIL PROTECTED] ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] user defined settings (aka user defined guc variables)
On Wed, 18 Dec 2002, Bruce Momjian wrote: > > What exactly can you do with these variables other than SHOW/SET. Seems > it would be nice if they could be used in queries, like in a special > table like sysvar: > > SELECT sysvar.fsync; Isn't that just identical to having a table? Gavin ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] user defined settings (aka user defined guc variables)
Gavin Sherry wrote:
On Wed, 18 Dec 2002, Bruce Momjian wrote:
What exactly can you do with these variables other than SHOW/SET. Seems
it would be nice if they could be used in queries, like in a special
table like sysvar:
SELECT sysvar.fsync;
Isn't that just identical to having a table?
Well you can use it in a query:
regression=# select pg_create_user_setting('myvar',17,false);
pg_create_user_setting
17
(1 row)
regression=# select typname from pg_type where oid = current_setting('myvar');
typname
-
bytea
(1 row)
There are at least two differences to this approach vs a table:
1. Main reason is that if a user defined function/contrib module creates a
table in my database I consider that too intrusive. I'd prefer not to have
metadata tables in my database simply to support a loaded function.
2. It's faster. In some simple tests, I found that getting a setting value via
current_setting('myvar') is about 40% faster than getting a value from a one
row table, and about 100% faster than an indexed lookup in a larger table
(after the table is cached, more than that on the first lookup).
Joe
---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
SSL/TLS support (Was: Re: [HACKERS] 7.3.1 stamped)
On Wed, 18 Dec 2002, Bruce Momjian wrote: > scott.marlowe wrote: > > > I wasn't sure how insecure SSL2 was, and whether it allowed you to > > > authenticate without a password or something. > > > > SSL2 seems to get a lot of votes for being broken in ways that cannot be > > fixed because they aren't simple buffer overflows. see: > > > > http://www.lne.com/ericm/papers/ssl_servers.html#1.2 > > > > My suggestion would be to eventually phase out ssl2 in favor of ssl3 or > > tls. And, as we are phasing it out, make it an opt-in thing, where the > > dba has to turn on ssl2 KNOWING he is turning on a flawed protocol. > > That was sort of my point --- if we allow SSLv2 in the server, are we > open to any security problems? Maybe not. I just don't know. My understanding of SSL/TLS is that the DBA himself has to enable it ... there has to be a server/client key setup, similar to how it gets done with Apache for https connections ... can someone confirm whether this is the case? ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] 7.3.1 stamped
On Wed, 18 Dec 2002, Nathan Mueller wrote: > > At this point, all the SSL2 problems are conjecture on my part, which > > I > > don't understand. I hesitate to do anything until someone really > > knowledgeable can comment. Re-enabling SSL2 as part of 7.3.1 makes > > sense until we can get a definative answer on the risks involved. > > I'm not an expert, but as far as I know the only real differences > between SSLv2 and v3 (which isn't different from TLSv1 from a security > standpoint) are some things to prevent some man in the middle attacks. > > Thing is, most man in the middle attacks aren't that advanced. The > attacker will intercept your attempt to connect to the server, do > a handshake with you, do a handshake with the server and just sit > in between. The only way (that I know of) to defend against this > is to use certified public keys and I don't know of a way to do > that with postgres. > > In short, I wouldn't call SSLv2 insecure, just less secure then v3. I > think it's perfectly reasonable to phase it out, just not right now. > It'd be nice to have some sort of transition version so you wouldn't > have to switch over all your different client programs at the same time > you switch all the servers. My preference would be for backwords > compatibility in 7.3 and then eliminate it or provide a compile time > option in 7.4. If the client stays with TLSv1 newer clients will only > use the more secure protocols and older clients will still have the same > problems they did before. I don't think that's too much of a problem. Actually, would be nice if someone submit'd a patch that make choosing which method a configure option :) If nobody else does it, I'll try after I get back from my folks after the holidays ... ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: SSL/TLS support (Was: Re: [HACKERS] 7.3.1 stamped)
Marc G. Fournier wrote: > > > My suggestion would be to eventually phase out ssl2 in favor of ssl3 or > > > tls. And, as we are phasing it out, make it an opt-in thing, where the > > > dba has to turn on ssl2 KNOWING he is turning on a flawed protocol. > > > > That was sort of my point --- if we allow SSLv2 in the server, are we > > open to any security problems? Maybe not. I just don't know. > > My understanding of SSL/TLS is that the DBA himself has to enable it ... > there has to be a server/client key setup, similar to how it gets done > with Apache for https connections ... can someone confirm whether this is > the case? Uh, I just followed the steps in the PostgresSQL install instructions: openssl req -new -text -out server.req openssl rsa -in privkey.pem -out server.key rm privkey.pem openssl req -x509 -in server.req -text -key server.key -out server.crt chmod og-rwx server.key Isn't that similar to what was required in 7.2.X? -- 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 ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] 7.3.1 stamped
Marc G. Fournier wrote: > > In short, I wouldn't call SSLv2 insecure, just less secure then v3. I > > think it's perfectly reasonable to phase it out, just not right now. > > It'd be nice to have some sort of transition version so you wouldn't > > have to switch over all your different client programs at the same time > > you switch all the servers. My preference would be for backwords > > compatibility in 7.3 and then eliminate it or provide a compile time > > option in 7.4. If the client stays with TLSv1 newer clients will only > > use the more secure protocols and older clients will still have the same > > problems they did before. I don't think that's too much of a problem. > > Actually, would be nice if someone submit'd a patch that make choosing > which method a configure option :) > > If nobody else does it, I'll try after I get back from my folks after the > holidays ... Well, I had time to research it and looked at that URL on SSL2 vunerabilities. Seems all the problems are with man in the middle cases, and with doconnections not being properly authenticated. They are not of the variety where you could just attach to the port and somehow bypass a password prompt or anything like that. If users always use TSL-capable clients, there shouldn't be any issue. I was kind of surprised that folks couldn't get the existing TLS code working because I had it working here, and I don't have the newest setup. I though that TSL support was merely having a more recent version of OpenSSL --- at least that's how I understood it from the SSL author Bear. -- 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 ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] 7.3.1 stamped
On Wed, 18 Dec 2002, Bruce Momjian wrote: > If users always use TSL-capable clients, there shouldn't be any issue. > I was kind of surprised that folks couldn't get the existing TLS code > working because I had it working here, and I don't have the newest > setup. I though that TSL support was merely having a more recent > version of OpenSSL --- at least that's how I understood it from the SSL > author Bear. Ya, but that makes an assumption that ppl clients aren't statically compiled, and don't have the TLS option ... ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] v7.3.1 tar ready ... please check it ...
'K, I'm going to remove the tar files ... Bruce, can you go through these and get them fixed up? Peter, I have to take part of the blame away from Tom ... I'm on the road tomrorow afternoon to Ontario, and won't be back online until *late* Fri, so we kinda rushed it all ... Tom, we tried ... I'll do up the tar ball on Friday, if everyone can tak the next day and a bit to make sure we haven't missed anything? On Thu, 19 Dec 2002, Peter Eisentraut wrote: > Marc G. Fournier writes: > > > Just curious as to whether any of this is critical enough to force a > > rebuild of the .tar.gz files, or can they wait until v7.3.2? That is my > > only concern ... we can do it, and I can do the announce in the morning > > instead of this evening, just want to make sure that its critical enough > > ... > > Well the changes are mostly about elimating incorrect information from the > release notes, which is surely critical, and putting in the correct > version number, which is also critical. And neither of these things can > wait for 7.3.2, because that would kind of defeat the point. If you jump > the gun with building the tarballs that's the price you have to pay. > > -- > Peter Eisentraut [EMAIL PROTECTED] > > ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] v7.3.1 tar ready ... please check it ...
At 11:26 PM 18/12/2002 -0400, Marc G. Fournier wrote: Tom, we tried ... I'll do up the tar ball on Friday, if everyone can tak the next day and a bit to make sure we haven't missed anything? Seeing the setting for MAX_FSM_RELATIONS bumped to 1000 would be good (patch already sent) Philip Warner| __---_ Albatross Consulting Pty. Ltd. |/ - \ (A.B.N. 75 008 659 498) | /(@) __---_ Tel: (+61) 0500 83 82 81 | _ \ Fax: (+61) 03 5330 3172 | ___ | Http://www.rhyme.com.au |/ \| |---- PGP key available upon request, | / and from pgp5.ai.mit.edu:11371 |/ ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] v7.3.1 tar ready ... please check it ...
I don't think we can bump that up in a minor. Should we? --- Philip Warner wrote: > At 11:26 PM 18/12/2002 -0400, Marc G. Fournier wrote: > >Tom, we tried ... I'll do up the tar ball on Friday, if everyone can tak > >the next day and a bit to make sure we haven't missed anything? > > Seeing the setting for MAX_FSM_RELATIONS bumped to 1000 would be good > (patch already sent) > > > > Philip Warner| __---_ > Albatross Consulting Pty. Ltd. |/ - \ > (A.B.N. 75 008 659 498) | /(@) __---_ > Tel: (+61) 0500 83 82 81 | _ \ > Fax: (+61) 03 5330 3172 | ___ | > Http://www.rhyme.com.au |/ \| > |---- > PGP key available upon request, | / > and from pgp5.ai.mit.edu:11371 |/ > > > ---(end of broadcast)--- > TIP 5: Have you checked our extensive FAQ? > > http://www.postgresql.org/users-lounge/docs/faq.html > -- 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 ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] v7.3.1 tar ready ... please check it ...
At 10:49 PM 18/12/2002 -0500, Bruce Momjian wrote: I don't think we can bump that up in a minor. Why not? It's a relatively serious problem with the default config. Should we? Yes. Philip Warner| __---_ Albatross Consulting Pty. Ltd. |/ - \ (A.B.N. 75 008 659 498) | /(@) __---_ Tel: (+61) 0500 83 82 81 | _ \ Fax: (+61) 03 5330 3172 | ___ | Http://www.rhyme.com.au |/ \| |---- PGP key available upon request, | / and from pgp5.ai.mit.edu:11371 |/ ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
