Re: [HACKERS] [GENERAL] SHA1 on postgres 8.3
On 1/20/08, Greg Sabino Mullane [EMAIL PROTECTED] wrote: In summary: what would objections be to my writing a sha1() patch? Well. If you do start adding hashes to core then _please_ pick a path that allows having all the standard hashes in advance. That means both md5 and sha-1, sha2 (4 hashes) and there is also sha-3 in the horizon. Basically there seems to be 2 variants: 1) Continue the md5() style: md5(), sha1(), sha224(), sha256(), sha384(), sha512(), plus another 4 for SHA-3. 2) Move hashing functions from pgcrypto to core. That means digest() and I would suggest hmac() and crypt() too. I'm also starting to think it may be worth having hexdigest(). I prefer 2). There is some common infrastructure in pgcrypto, the hash specific parts can be either split out or rewritten from scratch, hashes need very small amount of code. I agree that having all of pgcrypto in core is bit overkill, so please don't think of it as all-or-nothing affair. -- marko ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] Bug in psql/enum
On Sun, Jan 20, 2008 at 10:55:11PM -0500, Tom Lane wrote: David Fetter [EMAIL PROTECTED] writes: 8.3's psql is ponderously unhelpful when getting the type description of an enum, so I'd like to propose a new column in the \dT output which can contain those values in an array format. ... and how wide is your screen, again? Excellent point. How about stacking them together one per line? I guess this would need to be one thing for Windows and another for Everybody Else. How about putting it in the \dT+ output? Cheers, David. -- David Fetter [EMAIL PROTECTED] http://fetter.org/ Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter Skype: davidfetter XMPP: [EMAIL PROTECTED] Remember to vote! Consider donating to Postgres: http://www.postgresql.org/about/donate ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
[HACKERS] contrib like modules in Red Hat problem, Re: A bug report for orafce
Hello is any chance to share standard Makefile and RH Makefile? I am sorry. I don't understand to Makefile absolutely. It's look so global Makefile need some changes. Any help is welcome. Regards Pavel Stehule On 21/01/2008, Devrim GÜNDÜZ [EMAIL PROTECTED] wrote: Hi Pavel, Orafce is about to be approved for Fedora, and I need help for one of the review items. Per: https://bugzilla.redhat.com/show_bug.cgi?id=251805#c1 There is a comment: You should improve Makefile to enable to build with non-privilleged user See the attachment. make install tries to make a directory of /usr/share/pgsql/contrib, and %buildroot is not used. I could not build your package because of this problem. The log is here: https://bugzilla.redhat.com/attachment.cgi?id=172420 Could you please look at the reason why? I fixed the other issues in the spec file. Thanks a lot. Regards, -- Devrim GÜNDÜZ , RHCE PostgreSQL Replication, Consulting, Custom Development, 24x7 support Managed Services, Shared and Dedicated Hosting Co-Authors: plPHP, ODBCng - http://www.commandprompt.com/ ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] sun to buy mysql
On Sat, 19 Jan 2008, Jonah H. Harris wrote: Date: Sat, 19 Jan 2008 10:22:13 -0500 From: Jonah H. Harris [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: pgsql-hackers list pgsql-hackers@postgresql.org Subject: Re: [HACKERS] sun to buy mysql On Jan 19, 2008 10:01 AM, [EMAIL PROTECTED] wrote: I'm surprised no one mentioned here that Sun was ready to buy Mysql for $1 billion. Could it change something for postresql? if yes, what? Nobody mentioned it here, because this is the hackers list. It is mentioned in-depth on -advocacy. Oops, sorry for the noise! I should have read it first! -- Olivier PRENANT Tel: +33-5-61-50-97-00 (Work) 15, Chemin des Monges+33-5-61-50-97-01 (Fax) 31190 AUTERIVE +33-6-07-63-80-64 (GSM) FRANCE Email: [EMAIL PROTECTED] -- Make your life a dream, make your dream a reality. (St Exupery) ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] mklink of pg_standby
On Mon, Jan 21, 2008 at 03:36:29PM +0900, Hiroshi Saito wrote: Hi Simon, and Dave,Magnus. About pg_standby, a link option cause a problem in windows(XP and 2k,2k3). It is because the call of mklink is needed. Then, they are the new programs of VISTA and 2008. It is CreateSymbolicLink of API of kernel32.lib is equipped with mklink. http://msdn2.microsoft.com/en-us/library/aa363866.aspx Therefore, I considered whether it should correspond by the 'Junction' or the 'Hard Link' this way and that. However, The addition thought that it was not desirable by the reason of the process of evolution functional pg_standby. A copy function is no problem. However, I think that it is necessary to write it to a document in order to avoid a user's confusion. probably, has that no source code corrects. to Dave,and Magnus. You can do more honest suggestion.:-) Junctions only work for directories, not for files. In theory, you should be able to use mklink to create a hardlink on previous versions of Windows, but I'm not sure if it'll work. But we want symlinks here, not hardlinks, and they are simply not supported on earlier versions of Windows. It is alerady documented that it doesn't work on Windows prior to Vista. I think this is fine. What we could add is a specific version check to pg_standby to have it emit a not supported on this windows version error if it's not supported. But I think that's overkill - it will still fail, and it's well documented that it's not *supposed* to work. //Magnus ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] mklink of pg_standby
On Mon, Jan 21, 2008 at 07:33:57AM +, Simon Riggs wrote: On Mon, 2008-01-21 at 15:36 +0900, Hiroshi Saito wrote: Hi Simon, and Dave,Magnus. About pg_standby, a link option cause a problem in windows(XP and 2k,2k3). It is because the call of mklink is needed. Then, they are the new programs of VISTA and 2008. It is CreateSymbolicLink of API of kernel32.lib is equipped with mklink. http://msdn2.microsoft.com/en-us/library/aa363866.aspx Therefore, I considered whether it should correspond by the 'Junction' or the 'Hard Link' this way and that. However, The addition thought that it was not desirable by the reason of the process of evolution functional pg_standby. A copy function is no problem. However, I think that it is necessary to write it to a document in order to avoid a user's confusion. probably, has that no source code corrects. Hi Hiroshi, pg_standby uses mklink which defaults to creating symbolic links on Win2003 and Win2008: http://technet2.microsoft.com/windowsserver2008/en/library/0ce4df22-2dbc-48fc-9c16-b721ae85f8571033.mspx?mfr=true I think you're referring to the point that mklink is not available for XP and 2k. I assume you actually maen Vista + 2008? Symlinks aren't supported on Win2k3 AFAIK, and that page certainly says nothing about them. Plus, none of my 2k3 machines appear to have mklink.exe :-P //Magnus ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] mklink of pg_standby
Hi. - Original Message - From: Magnus Hagander [EMAIL PROTECTED] Junctions only work for directories, not for files. In theory, you should be able to use mklink to create a hardlink on previous versions of Windows, but I'm not sure if it'll work. But we want symlinks here, not hardlinks, and they are simply not supported on earlier versions of Windows. It is alerady documented that it doesn't work on Windows prior to Vista. I think this is fine. What we could add is a specific version check to pg_standby to have it emit a not supported on this windows version error if it's not supported. But I think that's overkill - it will still fail, and it's well documented that it's not *supposed* to work. Yeah, vote +1:-) Probably, the equipment which is not Symbolic Link is needed in order to correspond to XP and 2K. It is hard to use rather than 'SymbolicLink'. It will be enough if notice are written to a document. Regards, Hiroshi Saito ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] mklink of pg_standby
On Mon, Jan 21, 2008 at 10:11:52PM +0900, Hiroshi Saito wrote: Hi. - Original Message - From: Magnus Hagander [EMAIL PROTECTED] Junctions only work for directories, not for files. In theory, you should be able to use mklink to create a hardlink on previous versions of Windows, but I'm not sure if it'll work. But we want symlinks here, not hardlinks, and they are simply not supported on earlier versions of Windows. It is alerady documented that it doesn't work on Windows prior to Vista. I think this is fine. What we could add is a specific version check to pg_standby to have it emit a not supported on this windows version error if it's not supported. But I think that's overkill - it will still fail, and it's well documented that it's not *supposed* to work. Yeah, vote +1:-) Probably, the equipment which is not Symbolic Link is needed in order to correspond to XP and 2K. It is hard to use rather than 'SymbolicLink'. It will be enough if notice are written to a document. The notice is *alraedy* in the documentation. http://www.postgresql.org/docs/8.3/static/pgstandby.html has: -l will not work on versions of Windows prior to Vista. //Magnus ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] mklink of pg_standby
Hi. From: Magnus Hagander [EMAIL PROTECTED] Yeah, vote +1:-) Probably, the equipment which is not Symbolic Link is needed in order to correspond to XP and 2K. It is hard to use rather than 'SymbolicLink'. It will be enough if notice are written to a document. The notice is *alraedy* in the documentation. http://www.postgresql.org/docs/8.3/static/pgstandby.html has: -l will not work on versions of Windows prior to Vista. Ugaa, sorry this noise. , I had overlooked it. ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] Anyone tried PG with Perl 5.10?
-BEGIN PGP SIGNED MESSAGE- Hash: RIPEMD160 I read that Perl 5.10 is about to hit Fedora rawhide. Anyone know if it will work with plperl and/or DBD::Pg? If there are fixes needed in plperl, it'd sure be nice if they were in 8.3 ... I've tested 5.10 against both and they seem to work fine. My plperl tests are not necessarily thorough, but it compiled smoothly and ran a bunch of plperlu code without a problem. DBD::Pg worked fine, all its tests passed. -BEGIN PGP SIGNATURE- iD8DBQFHlLMevJuQZxSWSsgRA4neAJoCJtcPusA86PBpZHsmnSWyeKroQACg1CcS jVgOjqD8ousq5jxIJq3+Sbc= =XzXA -END PGP SIGNATURE- ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] Anyone tried PG with Perl 5.10?
Greg Sabino Mullane wrote: I read that Perl 5.10 is about to hit Fedora rawhide. Anyone know if it will work with plperl and/or DBD::Pg? If there are fixes needed in plperl, it'd sure be nice if they were in 8.3 ... I've tested 5.10 against both and they seem to work fine. My plperl tests are not necessarily thorough, but it compiled smoothly and ran a bunch of plperlu code without a problem. DBD::Pg worked fine, all its tests passed. For plperl, we need to test at least: * standard plperl regression tests * the UTF8 problem we recently fixed I can check this out later today. cheers andrew ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] [GENERAL] SHA1 on postgres 8.3
Florian Weimer [EMAIL PROTECTED] writes: * David Fetter: Is there any country with laws so benighted that they restrict secure hashing algorithms? Right now, there's a contest between SHA1 and MD5 as to which one gets broken first, and SHA1 appears to be in the lead. SHAn for n1 could preempt the awfulness of losing this race. MD5 is broken in the sense that you can create two or more meaningful documents with the same hash. Note that this isn't actually very interesting for the purpose for which the md5() function was put into core: namely, hashing passwords before they are stored in pg_authid. pg_authid is already secured against viewing by non-superusers, and a superuser can crack into your database account anyway, nyet? So the only reason we bother with hashing here is to keep a superuser from finding out your cleartext password, which might possibly let him crack into non-database services that you foolishly used the same password for. Therefore, it doesn't really matter if he can find another password with the same hash --- that's not guarding against anything interesting. Of course, if you want to store other sorts of protected stuff in the database, you might not want md5, but at that point you're a candidate to use contrib/pgcrypto. regards, tom lane ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] [GENERAL] SHA1 on postgres 8.3
* Tom Lane: MD5 is broken in the sense that you can create two or more meaningful documents with the same hash. Note that this isn't actually very interesting for the purpose for which the md5() function was put into core: namely, hashing passwords before they are stored in pg_authid. No doubt about that. But there are checklists out there, and if you use MD5 at some point, you need to go to some lengths to explain that it's okay. That's why I can understand the desire to have sha1 easily available (even though SHA-1 isn't much better, really, and the difference doesn't actually matter for many application). It's a bit like justifying that you don't need a virus scanner on your non-Windows server or database server. 8-P BTW, I'd like to see MD5/SHA-1 for BYTEA, not just TEXT, and with a BYTEA return value. Does pgcrypto provide that? -- Florian Weimer[EMAIL PROTECTED] BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstraße 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99 ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] Anyone tried PG with Perl 5.10?
I read that Perl 5.10 is about to hit Fedora rawhide. Anyone know if it will work with plperl and/or DBD::Pg? If there are fixes needed in plperl, it'd sure be nice if they were in 8.3 ... I tried and couldn't get the Debian perl 5.10 package installed without having apt tell me it wanted to uninstall all 700+ other packages. -- Gregory Stark EnterpriseDB http://www.enterprisedb.com Ask me about EnterpriseDB's Slony Replication support! ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] [GENERAL] SHA1 on postgres 8.3
On 1/21/08, Florian Weimer [EMAIL PROTECTED] wrote: BTW, I'd like to see MD5/SHA-1 for BYTEA, not just TEXT, and with a BYTEA return value. Does pgcrypto provide that? Yes. -- marko ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] [GENERAL] SHA1 on postgres 8.3
On 1/21/08, Tom Lane [EMAIL PROTECTED] wrote: MD5 is broken in the sense that you can create two or more meaningful documents with the same hash. Note that this isn't actually very interesting for the purpose for which the md5() function was put into core: namely, hashing passwords before they are stored in pg_authid. Note: this was bad idea. The function that should have been added to core would be pg_password_hash(username, password). Adding md5() lessens incentive to install pgcrypto or push/accept digest() into core and gives impression there will be sha1(), etc in the future. Now users who want to store passwords in database (the most popular usage) will probably go with md5() without bothering with pgcrypto. They probably see Postgres itself uses MD5 too, without realizing their situation is totally different from pg_authid one. It's like we have solution that is ACID-compliant 99% of the time in core, so why bother with 100% one. -- marko ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] contrib like modules in Red Hat problem, Re: A bug report for orafce
Pavel Stehule [EMAIL PROTECTED] writes: On 21/01/2008, Devrim GÃNDÃZ [EMAIL PROTECTED] wrote: Orafce is about to be approved for Fedora, and I need help for one of the review items. Per: https://bugzilla.redhat.com/show_bug.cgi?id=251805#c1 AFAICT, there's nothing wrong with the Makefile. The problem is with the specfile, which apparently is calling plain make install. It should read %install rm -rf $RPM_BUILD_ROOT make DESTDIR=$RPM_BUILD_ROOT install Devrim: you should be testing specfiles by building as non-root; you would have caught this yourself. regards, tom lane ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] contrib like modules in Red Hat problem, Re: A bug report for orafce
Tom Lane wrote: Pavel Stehule [EMAIL PROTECTED] writes: On 21/01/2008, Devrim GÃœNDÃœZ [EMAIL PROTECTED] wrote: Orafce is about to be approved for Fedora, and I need help for one of the review items. Per: https://bugzilla.redhat.com/show_bug.cgi?id=251805#c1 AFAICT, there's nothing wrong with the Makefile. The problem is with the specfile, which apparently is calling plain make install. It should read %install rm -rf $RPM_BUILD_ROOT make DESTDIR=$RPM_BUILD_ROOT install Devrim: you should be testing specfiles by building as non-root; you would have caught this yourself. Shouldn't one always build RPMs as non-root? cheers andrew ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] contrib like modules in Red Hat problem, Re: A bug report for orafce
Andrew Dunstan [EMAIL PROTECTED] writes: Tom Lane wrote: Devrim: you should be testing specfiles by building as non-root; you would have caught this yourself. Shouldn't one always build RPMs as non-root? That'd be my advice --- the other way is archaic, not to mention a bit of a security risk. regards, tom lane ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] contrib like modules in Red Hat problem, Re: A bug report for orafce
Hi, On Mon, 2008-01-21 at 11:26 -0500, Andrew Dunstan wrote: Shouldn't one always build RPMs as non-root? Probably, if the packager is not lazy ;) Regards, -- Devrim GÜNDÜZ , RHCE PostgreSQL Replication, Consulting, Custom Development, 24x7 support Managed Services, Shared and Dedicated Hosting Co-Authors: plPHP, ODBCng - http://www.commandprompt.com/ signature.asc Description: This is a digitally signed message part
Re: [HACKERS] contrib like modules in Red Hat problem, Re: A bug report for orafce
Tom Lane wrote: %install rm -rf $RPM_BUILD_ROOT make DESTDIR=$RPM_BUILD_ROOT install I hope nobody tries building in a directory with a space in it... -- Gregory Stark EnterpriseDB http://www.enterprisedb.com Ask me about EnterpriseDB's PostGIS support! ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] contrib like modules in Red Hat problem, Re: A bug report for orafce
Devrim =?ISO-8859-1?Q?G=DCND=DCZ?= [EMAIL PROTECTED] writes: On Mon, 2008-01-21 at 11:26 -0500, Andrew Dunstan wrote: Shouldn't one always build RPMs as non-root? Probably, if the packager is not lazy ;) It's really not hard, it just takes a couple of minutes of one-time setup. Make a file ~/.rpmmacros containing (in my case) %_topdir /home/tgl/rpmwork then create the directory ~/rpmwork and under it the five directories BUILD/RPMS/ SOURCES/ SPECS/SRPMS/ Now you put your SRPMS in ~/rpmwork/SRPMS and run rpmbuild there, same as you would do in /usr/src/redhat, you're just not root. Much safer. (Obviously, you can put your rpmwork directory wherever you want and call it whatever you want, adjusting the _topdir macro to match. What I show above is the customary thing for Red Hat engineers, though.) regards, tom lane ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] Anyone tried PG with Perl 5.10?
Andrew Dunstan wrote: Greg Sabino Mullane wrote: I read that Perl 5.10 is about to hit Fedora rawhide. Anyone know if it will work with plperl and/or DBD::Pg? If there are fixes needed in plperl, it'd sure be nice if they were in 8.3 ... I've tested 5.10 against both and they seem to work fine. My plperl tests are not necessarily thorough, but it compiled smoothly and ran a bunch of plperlu code without a problem. DBD::Pg worked fine, all its tests passed. For plperl, we need to test at least: * standard plperl regression tests * the UTF8 problem we recently fixed First news is not good. On my test we have failed one of the regression tests - the use strict processing seems to be backwards. I will try to get to the bottom of it. cheers andrew ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] contrib like modules in Red Hat problem, Re: A bug report for orafce
Hi, On Mon, 2008-01-21 at 12:31 -0500, Tom Lane wrote: It's really not hard, it just takes a couple of minutes of one-time setup. snip I *know* how to build the RPMs as non root :-) -- we are talking about ~60 servers to be setup like this . That's why it will take a bit time. I'll try to this asap. Regards, -- Devrim GÜNDÜZ , RHCE PostgreSQL Replication, Consulting, Custom Development, 24x7 support Managed Services, Shared and Dedicated Hosting Co-Authors: plPHP, ODBCng - http://www.commandprompt.com/ signature.asc Description: This is a digitally signed message part
Re: [HACKERS] contrib like modules in Red Hat problem, Re: A bug report for orafce
Devrim =?ISO-8859-1?Q?G=DCND=DCZ?= [EMAIL PROTECTED] writes: I *know* how to build the RPMs as non root :-) -- we are talking about ~60 servers to be setup like this . That's why it will take a bit time. You mean the RPM buildfarm? I would've thought that was already set up as non-root --- or are you skipping the regression-test step? regards, tom lane ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] contrib like modules in Red Hat problem, Re: A bug report for orafce
Hi, On Mon, 2008-01-21 at 13:08 -0500, Tom Lane wrote: I *know* how to build the RPMs as non root :-) -- we are talking about ~60 servers to be setup like this . That's why it will take a bit time. You mean the RPM buildfarm? Yes. I would've thought that was already set up as non-root No:( --- or are you skipping the regression-test step? Yes, that's why I could not find out the regression problem before you. Regards, -- Devrim GÜNDÜZ , RHCE PostgreSQL Replication, Consulting, Custom Development, 24x7 support Managed Services, Shared and Dedicated Hosting Co-Authors: plPHP, ODBCng - http://www.commandprompt.com/ signature.asc Description: This is a digitally signed message part
Re: [HACKERS] contrib like modules in Red Hat problem, Re: A bug report for orafce
Devrim GÜNDÜZ escribió: On Mon, 2008-01-21 at 12:31 -0500, Tom Lane wrote: It's really not hard, it just takes a couple of minutes of one-time setup. snip I *know* how to build the RPMs as non root :-) -- we are talking about ~60 servers to be setup like this . That's why it will take a bit time. You don't need to set up all the machines this way, only the one where you actually write and test the SPEC file. Anyway, a single file listing the 60 servers and a for loop in shell should be plenty to setup the environment Tom shows ... -- Alvaro Herrerahttp://www.CommandPrompt.com/ The PostgreSQL Company - Command Prompt, Inc. ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] contrib like modules in Red Hat problem, Re: A bug report for orafce
Alvaro Herrera [EMAIL PROTECTED] writes: You don't need to set up all the machines this way, only the one where you actually write and test the SPEC file. Well, actually, I'm fairly unhappy that Devrim's skipping the make check step while building those RPMs (which he must do because it won't work as root). So there seems to me to be plenty of argument for fixing the build farm too. But yeah, the immediate point is development of a new package's specfile, which you'd hardly do on a server farm. regards, tom lane ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
[HACKERS] Polyphase Merge
I'm trying to refine the sorting module of tuplesort.c During run creations I use two heaps instead of just one (yeah, it's still me... the one of the two heaps still trying to get some answer/help from -hackers) Those two runs are built in a way such that if we would concatenate one of them to the other one red upside down, they will still form a run (recall that following Knuth, a run is a sorted sequence of data). There are a lot of possibility that with that refinement logical runs could be longer than ordinary runs built by the ordinary replacement selection. Remark we build runs: logical runs it's just a concept used to understand why we build runs that way. ISSUES a) how to distribute logical runs (that is both of its physical runs) into tapes? b) one of the 2 physical runs of the logical run is to be red upside down while merging: how to efficiently do it? Well, that's all for now. Hope you can please give to me few seconds of you precious time. That would allow me to go on developing my refinement. Or at least tell me don't bother till the day next PostgreSQL release is out (when will it be released?) or don't bother anymore since nobody will ever answer to me. Thanks for your attention. Manolo.
Re: [HACKERS] [GENERAL] setof record out syntax and returning records
Tom Lane wrote: Alvaro Herrera [EMAIL PROTECTED] writes: alvherre=# set lc_messWARNING: problem in alloc set PL/PgSQL function context: detected write past chunk end in block 0xb541d0, chunk 0xb562c0 ages to 'C'; WARNING: problem in alloc set PL/PgSQL function context: detected write past chunk en d in block 0xb541d0, chunk 0xb562c0 SET Ugh. I could not reproduce this here though; there's some missing bit of context. Are you testing CVS HEAD? I assume you've got --enable-nls on, but what were the initial settings of lc_messages, the server locale, and the database encoding? False alarm, I think. I cleaned and rebuilt and now I can't reproduce it. -- Alvaro Herrerahttp://www.CommandPrompt.com/ The PostgreSQL Company - Command Prompt, Inc. ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] contrib like modules in Red Hat problem, Re: A bug report for orafce
Hi, On Mon, 2008-01-21 at 11:17 -0500, Tom Lane wrote: Devrim: you should be testing specfiles by building as non-root; you would have caught this yourself. Even though it means a lot of work in my current setup, this is what will happen eventually, especially after the Makefile.regress problem you found. I should have seen it before. Regards, -- Devrim GÜNDÜZ , RHCE PostgreSQL Replication, Consulting, Custom Development, 24x7 support Managed Services, Shared and Dedicated Hosting Co-Authors: plPHP, ODBCng - http://www.commandprompt.com/ signature.asc Description: This is a digitally signed message part
Re: [HACKERS] Polyphase Merge
On Mon, Jan 21, 2008 at 07:42:24PM +0100, [EMAIL PROTECTED] wrote: During run creations I use two heaps instead of just one (yeah, it's still me... the one of the two heaps still trying to get some answer/help from -hackers) Hi again! ISSUES a) how to distribute logical runs (that is both of its physical runs) into tapes? b) one of the 2 physical runs of the logical run is to be red upside down while merging: how to efficiently do it? It's really up to you to find answers to these questions, especially the first one. Once you've designed an efficient algorithm then the second point (which I'm interpreting as how you'd go about changing tuplestore(?) so that things can be read in reverse order) should just drop out as an implementation detail :) I'm guessing you'll end up not reading the store in reverse order but arranging things differently---it'll be interesting to see. What does your current code look like and how have you solved it there? If you've already written it then you'll need to be much more specific with your questions about integrating it into PG. Sam ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] [GENERAL] setof record out syntax and returning records
Alvaro Herrera [EMAIL PROTECTED] writes: False alarm, I think. I cleaned and rebuilt and now I can't reproduce it. Strange. Most of the time I'd have no problem writing this off as a build-synchronization error, but the tree has been so quiet lately due to the release cycle that this seems an odd time to be seeing such a problem. I did a quick look through the CVS logs and couldn't find any plausible-looking causes since the start of the year; except maybe this: http://developer.postgresql.org/cvsweb.cgi/pgsql/src/include/access/relscan.h.diff?r1=1.59;r2=1.60;f=h but alignment rules should have meant that that didn't really move any of the other fields. Anyway, if it went away on a clean rebuild, seems that a stale .o file must be the explanation. Do you normally use --enable-depend? regards, tom lane ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] Polyphase Merge
Sam Mason [EMAIL PROTECTED] writes: It's really up to you to find answers to these questions, especially the first one. Once you've designed an efficient algorithm then the second point (which I'm interpreting as how you'd go about changing tuplestore(?) so that things can be read in reverse order) should just drop out as an implementation detail :) I'm guessing you'll end up not reading the store in reverse order but arranging things differently---it'll be interesting to see. I agree --- having to read the run back from external storage, only to write it out again with no further useful work done on it, sounds like a guaranteed loser. To make this work you'll need some kind of ju-jitsu rearrangement that logically puts the run where it needs to go without physically moving any data. regards, tom lane ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
[HACKERS] Strange locking choices in pg_shdepend.c
I came across some rather strange choices of lock levels in pg_shdepend.c. Why does shdepDropOwned() take AccessExclusiveLock on pg_shdepend? Seems like RowExclusiveLock should be sufficient. If it isn't sufficient, I wonder whether the other functions in here are taking strong enough locks. It's probably not a good idea to have shdepReassignOwned() take only AccessShareLock on pg_shdepend. Even though the function itself merely reads the table, it is going to call functions that will take RowExclusiveLock, meaning that we're setting ourselves up for potential deadlock failures due to lock-upgrade. It'd be safer (and faster too) to just hold RowExclusiveLock through the whole operation. regards, tom lane ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] [GENERAL] setof record out syntax and returning records
Tom Lane wrote: Strange. Most of the time I'd have no problem writing this off as a build-synchronization error, but the tree has been so quiet lately due to the release cycle that this seems an odd time to be seeing such a problem. This was on a laptop I hadn't used in some time, and I think I must have done make install in, for example, src/backend only. Normally, I use my do-it-all script which zaps the entire install tree, but sometimes I don't. Anyway, if it went away on a clean rebuild, seems that a stale .o file must be the explanation. Do you normally use --enable-depend? Yes. -- Alvaro Herrerahttp://www.CommandPrompt.com/ The PostgreSQL Company - Command Prompt, Inc. ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] Strange locking choices in pg_shdepend.c
Tom Lane wrote: I came across some rather strange choices of lock levels in pg_shdepend.c. Why does shdepDropOwned() take AccessExclusiveLock on pg_shdepend? Seems like RowExclusiveLock should be sufficient. If it isn't sufficient, I wonder whether the other functions in here are taking strong enough locks. Hmm, I can't recall nor deduce any reason for that. Perhaps the intention was to protect against itself; but I think this should only matter if we're dropping the same role concurrently (otherwise the to-be-dropped objects would be disjoint sets, so it doesn't matter), which should be already protected by the lock on the role itself. Hmm, unless revoking privileges concurrently, for two different users on the same object could cause a problem? I don't see us grabbing a lock on the object itself -- does this matter? It's probably not a good idea to have shdepReassignOwned() take only AccessShareLock on pg_shdepend. Even though the function itself merely reads the table, it is going to call functions that will take RowExclusiveLock, meaning that we're setting ourselves up for potential deadlock failures due to lock-upgrade. It'd be safer (and faster too) to just hold RowExclusiveLock through the whole operation. Huh, correct. I think this was just an oversight. -- Alvaro Herrerahttp://www.CommandPrompt.com/ The PostgreSQL Company - Command Prompt, Inc. ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
[HACKERS] Thoughts about bug #3883
Steven Flatt's report in this thread: http://archives.postgresql.org/pgsql-bugs/2008-01/msg00138.php exposes two more-or-less-independent flaws. One problem is that we allow operations like TRUNCATE on tables that are open in the current backend. This poses a risk of strange behavior, such as regression=# create table foo as select x from generate_series(1,1000) x; SELECT regression=# begin; BEGIN regression=# declare c cursor for select * from foo; DECLARE CURSOR regression=# fetch 10 from c; x 1 2 3 4 5 6 7 8 9 10 (10 rows) regression=# truncate foo; TRUNCATE TABLE regression=# fetch 10 from c; x 11 12 13 14 15 16 17 18 19 20 (10 rows) regression=# fetch all from c; ERROR: could not read block 1 of relation 1663/133283/156727: read only 0 of 8192 bytes It's not too consistent that we could still read rows from c until we needed to fetch the next page of the table. For more complex queries involving indexscans, I'm afraid the behavior could be even more bizarre. What I propose we do about this is put the same check into TRUNCATE, CLUSTER, and REINDEX that is already in ALTER TABLE, namely that we reject the command if the current transaction is already holding the table open. The issue Steven directly complained of is a potential for undetected deadlock via LockBufferForCleanup. Ordinarily, buffer-level locks don't pose a deadlock risk because we don't hold one while trying to acquire another (except in UPDATE, which uses an ordering rule to avoid the risk). The problem with LockBufferForCleanup is that it can be blocked by a mere pin, which another backend could well hold while trying to acquire a lock that will be blocked by VACUUM. There are a couple of migitating factors: first, patching TRUNCATE et al as suggested above will prevent the immediate case, and second, as of 8.3 this isn't a problem for autovacuum because of the facility for kicking autovacuum off a table if it's blocking someone else's lock request. Still, undetected deadlocks are unpleasant, so it'd be nice to have some way to recognize the situation if we do get into it. I have no idea about a reasonable way to do that though. Getting the heavyweight lock manager involved in buffer accesses seems right out on performance grounds. Comments, ideas? regards, tom lane ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] [GENERAL] setof record out syntax and returning records
Alvaro Herrera [EMAIL PROTECTED] writes: Tom Lane wrote: Strange. Most of the time I'd have no problem writing this off as a build-synchronization error, but the tree has been so quiet lately due to the release cycle that this seems an odd time to be seeing such a problem. This was on a laptop I hadn't used in some time, and I think I must have done make install in, for example, src/backend only. Ah. That could explain it, if you had a plpgsql.so that was quite out of date compared to the backend. OK, then I'm prepared to forget about this one ... regards, tom lane ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
[HACKERS] Makefile support for Mac OS X Fat Binaries?
would the community accept a patch that would allow the making of 4-way fat binaries on Mac OS X 10.5+? (Obviously for 8.4+). I'm thinking about attempting it for an inside project here at work, but was wondering if there was community interest? Thanks! -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 512-248-2683 E-Mail: [EMAIL PROTECTED] US Mail: 430 Valona Loop, Round Rock, TX 78681-3893 ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] Makefile support for Mac OS X Fat Binaries?
Larry Rosenman [EMAIL PROTECTED] writes: would the community accept a patch that would allow the making of 4-way fat binaries on Mac OS X 10.5+? (Obviously for 8.4+). Depends on how big and ugly it is, I think. If you can do it just by hacking CFLAGS and friends, sure; if it's as invasive as the Windows build machinery, definitely not; in between, we'd have to see it. regards, tom lane ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] Makefile support for Mac OS X Fat Binaries?
On Mon, 21 Jan 2008, Tom Lane wrote: Larry Rosenman [EMAIL PROTECTED] writes: would the community accept a patch that would allow the making of 4-way fat binaries on Mac OS X 10.5+? (Obviously for 8.4+). Depends on how big and ugly it is, I think. If you can do it just by hacking CFLAGS and friends, sure; if it's as invasive as the Windows build machinery, definitely not; in between, we'd have to see it. I know I'm going to have to make a few lipo runs, and shell for-loops to make the different SUBSYS.o's. (ld by itself won't do it). I'll see how grotty it is, but I don't think it will be nearly as bad as the Windows machinery. regards, tom lane -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 512-248-2683 E-Mail: [EMAIL PROTECTED] US Mail: 430 Valona Loop, Round Rock, TX 78681-3893 ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] Makefile support for Mac OS X Fat Binaries?
Tom Lane [EMAIL PROTECTED] writes: Larry Rosenman [EMAIL PROTECTED] writes: would the community accept a patch that would allow the making of 4-way fat binaries on Mac OS X 10.5+? (Obviously for 8.4+). Depends on how big and ugly it is, I think. If you can do it just by hacking CFLAGS and friends, sure; if it's as invasive as the Windows build machinery, definitely not; in between, we'd have to see it. We've been through this once already. You can't do it (cleanly) with just Makefile hackery. The architectures have different endianness and possibly other ABI differences. To handle that cleanly you have to run configure once for each architecture and build each architecture with the appropriate config.h. -- Gregory Stark EnterpriseDB http://www.enterprisedb.com Ask me about EnterpriseDB's On-Demand Production Tuning ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] Makefile support for Mac OS X Fat Binaries?
On Tue, 22 Jan 2008, Gregory Stark wrote: Tom Lane [EMAIL PROTECTED] writes: Larry Rosenman [EMAIL PROTECTED] writes: would the community accept a patch that would allow the making of 4-way fat binaries on Mac OS X 10.5+? (Obviously for 8.4+). Depends on how big and ugly it is, I think. If you can do it just by hacking CFLAGS and friends, sure; if it's as invasive as the Windows build machinery, definitely not; in between, we'd have to see it. We've been through this once already. You can't do it (cleanly) with just Makefile hackery. The architectures have different endianness and possibly other ABI differences. To handle that cleanly you have to run configure once for each architecture and build each architecture with the appropriate config.h. Could we then combine the executables into one 4-way fat binary ? I'll see what I come up with. -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 512-248-2683 E-Mail: [EMAIL PROTECTED] US Mail: 430 Valona Loop, Round Rock, TX 78681-3893 ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
Re: [HACKERS] Strange locking choices in pg_shdepend.c
Alvaro Herrera [EMAIL PROTECTED] writes: Tom Lane wrote: Why does shdepDropOwned() take AccessExclusiveLock on pg_shdepend? Hmm, I can't recall nor deduce any reason for that. Perhaps the intention was to protect against itself; but I think this should only matter if we're dropping the same role concurrently (otherwise the to-be-dropped objects would be disjoint sets, so it doesn't matter), which should be already protected by the lock on the role itself. Hmm, unless revoking privileges concurrently, for two different users on the same object could cause a problem? I don't see us grabbing a lock on the object itself -- does this matter? Well, if there is any such problem then it could be triggered by two independent plain-ol-REVOKE commands, so I still don't see an argument why shdepDropOwned is more at risk than anything else. I think we should just downgrade the lock. regards, tom lane ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] Anyone tried PG with Perl 5.10?
Andrew Dunstan wrote:
Andrew Dunstan wrote:
Greg Sabino Mullane wrote:
I read that Perl 5.10 is about to hit Fedora rawhide. Anyone know if
it will work with plperl and/or DBD::Pg? If there are fixes needed
in plperl, it'd sure be nice if they were in 8.3 ...
I've tested 5.10 against both and they seem to work fine. My plperl
tests
are not necessarily thorough, but it compiled smoothly and ran a
bunch of
plperlu code without a problem. DBD::Pg worked fine, all its tests
passed.
For plperl, we need to test at least:
* standard plperl regression tests
* the UTF8 problem we recently fixed
First news is not good. On my test we have failed one of the
regression tests - the use strict processing seems to be backwards.
I will try to get to the bottom of it.
This problem has been identified by Simon Cozens as a bug in perl 5.10
(in that it is an undocumented change in Safe.pm). he will file a perl
bug report on it. The small patch below (also his suggestion, more or
less) fixes the problem. We turn on access to the caller opcode just
while we load the strict module. This should be perfectly safe. I intend
to apply it shortly and to backpatch it, unless there's an objection.
The UTF8 code appears to be still working, which was the other concern I
had.
cheers
andrew
Index: plperl.c
===
RCS file: /cvsroot/pgsql/src/pl/plperl/plperl.c,v
retrieving revision 1.134
diff -c -u -r1.134 plperl.c
cvs diff: conflicting specifications of output style
--- plperl.c1 Dec 2007 17:58:42 - 1.134
+++ plperl.c22 Jan 2008 02:31:08 -
@@ -272,8 +272,8 @@
sub ::mksafefunc { \
my $ret = $PLContainer-reval(qq[sub { $_[0] $_[1] }]); \
$@ =~ s/\\(eval \\d+\\) //g if $@; return $ret; } \
- $PLContainer-permit('require'); $PLContainer-reval('use
strict;'); \
- $PLContainer-deny('require'); \
+ $PLContainer-permit(qw[require caller]);
$PLContainer-reval('use strict;'); \
+ $PLContainer-deny(qw[require caller]); \
sub ::mk_strict_safefunc { \
my $ret = $PLContainer-reval(qq[sub { BEGIN {
strict-import(); } $_[0] $_[1] }]); \
$@ =~ s/\\(eval \\d+\\) //g if $@; return $ret; }
---(end of broadcast)---
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly
Re: [HACKERS] Makefile support for Mac OS X Fat Binaries?
Larry Rosenman [EMAIL PROTECTED] writes: On Tue, 22 Jan 2008, Gregory Stark wrote: We've been through this once already. You can't do it (cleanly) with just Makefile hackery. The architectures have different endianness and possibly other ABI differences. To handle that cleanly you have to run configure once for each architecture and build each architecture with the appropriate config.h. Could we then combine the executables into one 4-way fat binary ? Maybe you need to be thinking about a script that is outside the build system: run the configure/make/make install process 4 times, then combine the results. You could use the fact that some file is not the same in all 4 install trees as the trigger driving a combination process. (Shades of multilib RPMs ...) regards, tom lane ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
[HACKERS] find_typedef alternative that works on mainstream systems
Hi,
I just came across objdump -W which dumps the DWARF info from a object
file. This is useful to build a typedef file for pgindent. It can be
used like this:
objdump -W $object_file | \
awk '/DW_TAG_/ { grab=0 } /DW_TAG_typedef/ { grab=1 } /DW_AT_name/ { if (grab)
{ print $0 } }' | \
sed -e 's/^.*: \([^ ]*\)/\1/' | \
sort | \
uniq
I am disappointed by the fact that our current find_typedef script only
works on Bruce's rare platforms -- and we stopped shipping a standard
typedef file, which makes the problem worse.
--
Alvaro Herrerahttp://www.CommandPrompt.com/
PostgreSQL Replication, Consulting, Custom Development, 24x7 support
signature.asc
Description: Digital signature
Re: [HACKERS] find_typedef alternative that works on mainstream systems
Alvaro Herrera wrote:
objdump -W $object_file | \
awk '/DW_TAG_/ { grab=0 } /DW_TAG_typedef/ { grab=1 } /DW_AT_name/ { if
(grab) { print $0 } }' | \
sed -e 's/^.*: \([^ ]*\)/\1/' | \
sort | \
uniq
I oversimplified the awk line, causing some garbage to appear at the end
:-( The full awk line I am using is
awk '
/^Contents of / { if (read) exit }
/^The section / { if (read) exit }
/^The section .debug_info contains:/ { read=1 }
/DW_TAG_/ { grab=0 }
/DW_TAG_typedef/ { grab=1 }
/DW_AT_name/ { if (read grab) { print $0 } }
'
--
Alvaro Herrerahttp://www.CommandPrompt.com/
PostgreSQL Replication, Consulting, Custom Development, 24x7 support
---(end of broadcast)---
TIP 4: Have you searched our list archives?
http://archives.postgresql.org
