Re: [PATCHES] win32.mak patch
On Wed, Dec 19, 2007 at 11:19:54AM +0900, Hiroshi Saito wrote: Ummm, Sorry...former patch to be disregarded. Although 64bit mak is experimental, it needs to be compiled. Please apply this. Is this really correct? Fromw hat I can tell you *both* tell us not to check the value *and* set the value? Shouldn't we be doing just one of them? //Magnus ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
Re: [PATCHES] Doc-patch: PAM authentication fails for local UNIX users
On Tue, Dec 18, 2007 at 12:41:56PM +0530, Dhanaraj M wrote: Hi all, This is the continuation to the discussion that we had in the hacker's list. http://archives.postgresql.org/pgsql-hackers/2007-08/msg00684.php Here, I like to add some details in 20.2.6. PAM authentication section. http://www.postgresql.org/docs/8.2/interactive/auth-methods.html#AUTH-PAM Can someone review and make changes, if required? Thanks. Eh, those extensions are only valid if you use PAM with a shadow password file, no? You shouldn't need root if you use say PAM-with-LDAP? //Magnus ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
Re: [PATCHES] [HACKERS] buildenv.pl/buildenv.bat
On Fri, Dec 14, 2007 at 10:47:02AM -0500, Andrew Dunstan wrote: Magnus Hagander wrote: On Fri, Dec 14, 2007 at 03:39:14PM +, Dave Page wrote: Andrew Dunstan wrote: Writing and calling a temp .bat file might be yucky - having to keep two environment files is a lot more yucky, IMNSHO, and we shouldn't make people do it. +1 Ok, I guess I'm outvoted ;-) I don't care *that* much about it, so let's do it your way. You need help testing that patch further, or do you consider it ready for application? If so, go. Yes, please do test it - I don't use buildenv.* at all normally, as then buildfarm client takes care of its own environment, and that's what I usually use to build on Windows. It works in my two standalone environments (win32 and win64 machine), so I've applied the patch now to get full buildfarm testing. //Magnus ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [PATCHES] Doc-patch: PAM authentication fails for local UNIX users
Magnus Hagander wrote: On Tue, Dec 18, 2007 at 12:41:56PM +0530, Dhanaraj M wrote: Hi all, This is the continuation to the discussion that we had in the hacker's list. http://archives.postgresql.org/pgsql-hackers/2007-08/msg00684.php Here, I like to add some details in 20.2.6. PAM authentication section. http://www.postgresql.org/docs/8.2/interactive/auth-methods.html#AUTH-PAM Can someone review and make changes, if required? Thanks. Eh, those extensions are only valid if you use PAM with a shadow password file, no? You shouldn't need root if you use say PAM-with-LDAP? Also, it strikes me that granting the postgres user read access to the shadow file is probably very poor security practice, and not something I would want to recommend without considerable thought. What we should say, rather, is that PAM auth is likely to fail if your PAM is set up to use the shadow file rather than an auth source such as LDAP which does not require privileged file access. cheers andrew ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [PATCHES] [HACKERS] Proposal for Null Bitmap Optimization(for TrailingNULLs)
I have submitted the first working patch for the trailing null optimization. It currently does the following a) Doesn't store the null bitmap, if the heap tuple / index tuple contains only trailing nulls b) In Heap Tuple, the trailing nulls won't occupy space in the null bitmap. The General design is like this a) After checking for trailing nulls, i reduce the number of attributes field, which gets stored in each heap tuple. b) For Index, i have changed the Index_form_tuple to store the unaligned total size in the size mask. While navigating through the index tuple, if the offset exceeds the unaligned total size stored, then a null is returned Please review it and provide suggestions. I doubt you have fixed it; I doubt it's *possible* to fix it without significant rejiggering of IndexTuple representation. The problem is that IndexTuple lacks a number-of-fields field, so there is no place to indicate how many null bitmap bits you have actually stored. Actually i have made one change to the structure of IndexTupleData. Instead of storing the Aligned size in the size mask, i have stored the un-aligned size. I am storing the size before the final MAXALIGN. The interface remains un-changed. IndexTupleSize does a MAXALIGN before returning the size value. so the interface remains un-changed. The advantage of storing the un-aligned size is that we can get both aligned size and un-aligned size(As you may know). I have created two more macros to return the un-aligned size. I would suggest forgetting that part and submitting the part that has some chance of getting accepted. Actually i want to submit the patch, which is best according to me. I suspect there's also an awkward case that *does* need to handled when you insert a tuple which has a null column which you're leaving out of the tuple but which appears in an index. You would have to make sure that the index tuple has that datum listed as NULL even though it's entirely missing from the heap tuple. Actually this is taken care because of your suggestion. When you add a new column, it doesn't appear in the heaptuple, but if you create an index on that column afterwards, the case is handled. There is a field in HeapTuple, which mentions the number of attributes in the tuple. If we are requesting for attribute numbers greater than this number, it is returned as null. So that problem was taken care. -- Thanks, Gokul. CertoSQL Project, Allied Solution Group. (www.alliedgroups.com) trailing-nulls.patch.gz Description: GNU Zip compressed data ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [PATCHES] [HACKERS] Proposal for Null Bitmap Optimization(for TrailingNULLs)
Gokulakannan Somasundaram wrote: I would suggest forgetting that part and submitting the part that has some chance of getting accepted. Actually i want to submit the patch, which is best according to me. That's not an attitude that is likely to succeed - you need to take suggestions from Tom very seriously. Also, please submit patches as context diffs, as set out in the Developer FAQ, which you should probably read carefully: http://www.postgresql.org/docs/faqs.FAQ_DEV.html cheers andrew ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
[PATCHES] Re: [HACKERS] Proposal for Null Bitmap Optimization(for TrailingNULLs)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Wed, 19 Dec 2007 13:46:15 -0500 Andrew Dunstan [EMAIL PROTECTED] wrote: I would suggest forgetting that part and submitting the part that has some chance of getting accepted. Actually i want to submit the patch, which is best according to me. You do need to be able to be able to feel that your work is up to a standard that you find redeemable. However... That's not an attitude that is likely to succeed - you need to take suggestions from Tom very seriously. Andrew is absolutely correct here. If you do not agree with Tom, you best prove why. Otherwise your patch will likely be ignored on submission. Sincerely, Joshua D. Drake - -- The PostgreSQL Company: Since 1997, http://www.commandprompt.com/ Sales/Support: +1.503.667.4564 24x7/Emergency: +1.800.492.2240 Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate SELECT 'Training', 'Consulting' FROM vendor WHERE name = 'CMD' -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFHaWj9ATb/zqfZUUQRAqsNAJ9k6p0z7rQEcqal0JoKw/ZZG8h5kACfaB9y xQJ4O+h1xe947O1gnTLEbTU= =WaSW -END PGP SIGNATURE- ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [PATCHES] win32.mak patch
Hi. - Original Message - From: Magnus Hagander [EMAIL PROTECTED] On Wed, Dec 19, 2007 at 11:19:54AM +0900, Hiroshi Saito wrote: Ummm, Sorry...former patch to be disregarded. Although 64bit mak is experimental, it needs to be compiled. Please apply this. Is this really correct? Fromw hat I can tell you *both* tell us not to check the value *and* set the value? Shouldn't we be doing just one of them? The setup is not allowed in 64-bit build of VisualStudio. Then, It is not allowed although I use nmake. I did the work of 64-bit correspondence of 8.3 to libpq. However, Although it is not declared by release, win32.mak has. I said that 64 bits of libpq(s) were required, in order that psqlODBC might guide 64 bits formally. Then, I and Inoue-san have lost timing in the reason for not having sufficient examination environment. But, We have compile environment. Then, It borrows an external machine and has performed only the easy examination -- add the _USE_32BIT_TIME_T for 64bit compile environment -- echo #define SYSCONFDIR pg_config_paths.h cl.exe /nologo /W3 /EHsc /O2 /MD /I ..\..\include /I ..\..\include\po rt\win32 /I ..\..\include\port\win32_msvc /I ..\..\port /I. /I C:\OpenSSL\ include /D FRONTEND /D NDEBUG /D _USE_32BIT_TIME_T /D WIN32 /D _WINDOWS /Fp.\Release\libpq.pch /Fo.\Release\\ /Fd.\Release\\ /FD /c /D _CRT_S ECURE_NO_DEPRECATE /D WIN64 /Wp64 /GS /D ENABLE_THREAD_SAFETY win32.c win32.c C:\Program Files\Microsoft Visual Studio 8\VC\include\crtdefs.h(493) : fatal err or C1189: #error : You cannot use 32-bit time_t (_USE_32BIT_TIME_T) with _WIN64 NMAKE : fatal error U1077: 'cl.exe' : return code '0x2' Stop. NMAKE : fatal error U1077: 'C:\Program Files\Microsoft Platform SDK\Bin\nmake.e xe' : return code '0x2' Stop. -- END -- I'm always realistic. what do you think? Regards, Hiroshi Saito ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
