Re: [HACKERS] psql questions: SQL, progname, copyright dates
I think adding 'S' to \df confuses more than it helps. Why that? Imho it would be consistent. Andreas ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] APR 1.0 released
Well, it's easily changed, if all that's needed is a search-and-replace. Suggestions for a better name? MINGW32 I think that is a bad idea. That symbol sure suggests, that you are using mingw. Are you expecting someone who creates a VisualStudio project to define MINGW32 ? Andreas ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] psql questions: SQL, progname, copyright dates
Robert Treat wrote: Ugh. If I want to see the syntax of my functions, I'd be forced to use the \df-+ syntax, and I'd argue people spend far more time wanting to see \df+ output on their own functions than they ever do on system functions. imho the argument against \dfS is pretty weak. Letters are not only used as object specifiers, they are also used for setting field separators, html output, switching to and from expanded output, and listing table access permissions, among other things. Telling folks that the S modifier is for system objects mnemonic, simple, and FWIW keeps with backward compatability. One thing is emerging from this thread: the \xyzk functionality is overloaded. Time to switch to something more human readable ? Regards Gaetano Mendola ---(end of broadcast)--- TIP 8: explain analyze is your friend
[HACKERS] Failed assertion, CVS head
Hi, I am using a version of PostgreSQL compiled from a CVS update of yesterday, and compiled with make clean all make install One client connection to the database doing routine and low volume population scripts (using schemas) After several normal runs of the population script, a run caused the following trap, and an associated backend halt. TRAP: FailedAssertion(!(((ntp)-t_data)-t_infomask 0x0010), File: catcache.c, Line: 1728) I know this is not a lot of data for a determination of cause, but I have only had a single instance of this happening, and thought it should at least be documented. Regards, Grant ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] APR 1.0 released
Bruce Momjian schrieb: Andrew Dunstan wrote: Reini Urban wrote: FYI: WIN32 is also defined because windows.h is included. (/usr/incluse/w32api/windef.h) If you want this or that, do proper nesting, and use #else. Ugh, yes. A little experimentation shows that __WIN32__ is defined for MinGW only, but WIN32 is for both. I wonder how we missed that in various places. Maybe we need a little audit of the use of WIN32. OK, fixed. We should not be using __WIN32__, just Win32. The proper test is #ifndef __CYGWIN__. very good. just think of future MSVC versions. Just one more glitch: #undef rename #undef unlink has to be defined before #include unistd.h on CYGWIN, because unistd.h has the declarations for rename and unlink, which are required inside the pg versions. without the #undef, the macros which rename rename to pgrename, ... are still effective, which will lead to undeclared/falsely autodeclared rename/unlink parts. I don't know for mingw, if they need the pgrename/pgunlink declaration. For my CYGWIN patch I moved those two lines before #include unistd.h. Index: src/port/dirmod.c === RCS file: /cvsroot/pgsql-server/src/port/dirmod.c,v retrieving revision 1.23 diff -c -c -r1.23 dirmod.c *** src/port/dirmod.c 9 Sep 2004 00:59:49 - 1.23 --- src/port/dirmod.c 10 Sep 2004 02:44:19 - *** *** 36,45 #undef rename #undef unlink ! #ifdef __WIN32__ #include winioctl.h #else - /* __CYGWIN__ */ #include windows.h #include w32api/winioctl.h #endif --- 36,44 #undef rename #undef unlink ! #ifndef __CYGWIN__ #include winioctl.h #else #include windows.h #include w32api/winioctl.h #endif -- Reini Urban http://xarch.tu-graz.ac.at/home/rurban/ ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] psql questions: SQL, progname, copyright dates
Zeugswetter Andreas SB SD wrote: I think adding 'S' to \df confuses more than it helps. Why that? Imho it would be consistent. I thought it was strange to have alphabetic modifiers but I seem to be the only one who is worried about it so forget my objection. -- 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] APR 1.0 released
OK, moved and comment documents its location. --- Reini Urban wrote: Bruce Momjian schrieb: Andrew Dunstan wrote: Reini Urban wrote: FYI: WIN32 is also defined because windows.h is included. (/usr/incluse/w32api/windef.h) If you want this or that, do proper nesting, and use #else. Ugh, yes. A little experimentation shows that __WIN32__ is defined for MinGW only, but WIN32 is for both. I wonder how we missed that in various places. Maybe we need a little audit of the use of WIN32. OK, fixed. We should not be using __WIN32__, just Win32. The proper test is #ifndef __CYGWIN__. very good. just think of future MSVC versions. Just one more glitch: #undef rename #undef unlink has to be defined before #include unistd.h on CYGWIN, because unistd.h has the declarations for rename and unlink, which are required inside the pg versions. without the #undef, the macros which rename rename to pgrename, ... are still effective, which will lead to undeclared/falsely autodeclared rename/unlink parts. I don't know for mingw, if they need the pgrename/pgunlink declaration. For my CYGWIN patch I moved those two lines before #include unistd.h. Index: src/port/dirmod.c === RCS file: /cvsroot/pgsql-server/src/port/dirmod.c,v retrieving revision 1.23 diff -c -c -r1.23 dirmod.c *** src/port/dirmod.c 9 Sep 2004 00:59:49 - 1.23 --- src/port/dirmod.c 10 Sep 2004 02:44:19 - *** *** 36,45 #undef rename #undef unlink ! #ifdef __WIN32__ #include winioctl.h #else - /* __CYGWIN__ */ #include windows.h #include w32api/winioctl.h #endif --- 36,44 #undef rename #undef unlink ! #ifndef __CYGWIN__ #include winioctl.h #else #include windows.h #include w32api/winioctl.h #endif -- Reini Urban http://xarch.tu-graz.ac.at/home/rurban/ -- 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 Index: src/port/dirmod.c === RCS file: /cvsroot/pgsql-server/src/port/dirmod.c,v retrieving revision 1.24 diff -c -c -r1.24 dirmod.c *** src/port/dirmod.c 10 Sep 2004 02:49:37 - 1.24 --- src/port/dirmod.c 10 Sep 2004 09:51:12 - *** *** 21,26 --- 21,32 #include postgres_fe.h #endif + /* Don't modify declarations in system headers */ + #if defined(WIN32) || defined(__CYGWIN__) + #undef rename + #undef unlink + #endif + #include unistd.h #include dirent.h #include sys/stat.h *** *** 33,41 #include miscadmin.h - #undef rename - #undef unlink - #ifndef __CYGWIN__ #include winioctl.h #else --- 39,44 ---(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] Failed assertion, CVS head
It's happened again, and in both cases seems to be on a call to VACUUM FULL Grant Finnemore wrote: Hi, I am using a version of PostgreSQL compiled from a CVS update of yesterday, and compiled with make clean all make install One client connection to the database doing routine and low volume population scripts (using schemas) After several normal runs of the population script, a run caused the following trap, and an associated backend halt. TRAP: FailedAssertion(!(((ntp)-t_data)-t_infomask 0x0010), File: catcache.c, Line: 1728) I know this is not a lot of data for a determination of cause, but I have only had a single instance of this happening, and thought it should at least be documented. Regards, Grant ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
[HACKERS] more dirmod CYGWIN (was: APR 1.0 released)
[BTW: there's no need to cc all, I'm subscribed to most lists] Reini Urban schrieb: Bruce Momjian schrieb: Andrew Dunstan wrote: Reini Urban wrote: FYI: WIN32 is also defined because windows.h is included. (/usr/incluse/w32api/windef.h) If you want this or that, do proper nesting, and use #else. Ugh, yes. A little experimentation shows that __WIN32__ is defined for MinGW only, but WIN32 is for both. I wonder how we missed that in various places. Maybe we need a little audit of the use of WIN32. OK, fixed. We should not be using __WIN32__, just Win32. The proper test is #ifndef __CYGWIN__. very good. just think of future MSVC versions. Just one more glitch: #undef rename #undef unlink has to be defined before #include unistd.h on CYGWIN, because unistd.h has the declarations for rename and unlink, which are required inside the pg versions. without the #undef, the macros which rename rename to pgrename, ... are still effective, which will lead to undeclared/falsely autodeclared rename/unlink parts. I don't know for mingw, if they need the pgrename/pgunlink declaration. For my CYGWIN patch I moved those two lines before #include unistd.h. FYI: latest cvs HEAD, without any patches. make runs now through with the expected implicit declaration warnings, but without any errors. Esp. the CYGWIN-specific SHMLIB linking errors are now gone. good! make[2]: Entering directory `/usr/src/postgresql/pgsql/src/port' gcc -O2 -fno-strict-aliasing -Wall -Wmissing-prototypes -Wmissing-declarations -I../../src/port -I../../src/include -c -o dirmod.o dirmod.c dirmod.c: In Funktion pgunlink: dirmod.c:113: Warnung: implicit declaration of function `unlink' dirmod.c: In Funktion rmt_cleanup: dirmod.c:267: Warnung: implicit declaration of function `pgport_pfree' dirmod.c: In Funktion rmtree: dirmod.c:318: Warnung: implicit declaration of function `pgport_palloc' dirmod.c:318: Warnung: Zuweisung erzeugt Zeiger von Ganzzahl ohne Typkonvertierung dirmod.c:333: Warnung: implicit declaration of function `pgport_pstrdup' dirmod.c:333: Warnung: Zuweisung erzeugt Zeiger von Ganzzahl ohne Typkonvertierung make check hangs at: running on port 65432 with pid 2304 == creating database regression == CREATE DATABASE ALTER DATABASE == dropping regression test user accounts == == installing PL/pgSQL== == running regression test queries== parallel group (13 tests): int2 int4 int8 float4 name varchar numeric which means rename works ok. probably the false implicit declarations in the memory code break it. I'll come with another patch later. -- Reini Urban http://xarch.tu-graz.ac.at/home/rurban/ ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] APR 1.0 released
Reini Urban wrote: Bruce Momjian schrieb: OK, care to submit a patch. As I remember the fix for rename/unlink also includes how the file is opened with flags. Anyway, we spent a lot of time on this so you will have to go back in the archvies to find it and determine how it can be improved. Your track record for Cygwin diagnosis isn't 100%. I am going to need complete research before changing anything at this point in beta. Ok, I'll do an analysis and patch which will have a chance to be accepted. Keeping pgrename in CYGWIN is probably a good idea. At least for consistent error reporting (which helped me in finding the problem) Personally I don't think that any rename()-usleep loop is necessary. I'll check the archives. I agree the rename loop seems unnecessary. I kept it in case we hadn't dealt with all the failure places. Should we remove them now or wait for 8.1? Seems we should keep them in and see if we get reports from users of looping forever, and if not we can remove them in 8.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 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] APR 1.0 released
Bruce Momjian schrieb: Reini Urban wrote: Bruce Momjian schrieb: OK, care to submit a patch. As I remember the fix for rename/unlink also includes how the file is opened with flags. Anyway, we spent a lot of time on this so you will have to go back in the archvies to find it and determine how it can be improved. Your track record for Cygwin diagnosis isn't 100%. I am going to need complete research before changing anything at this point in beta. Ok, I'll do an analysis and patch which will have a chance to be accepted. Keeping pgrename in CYGWIN is probably a good idea. At least for consistent error reporting (which helped me in finding the problem) Personally I don't think that any rename()-usleep loop is necessary. I'll check the archives. I agree the rename loop seems unnecessary. I kept it in case we hadn't dealt with all the failure places. Should we remove them now or wait for 8.1? Seems we should keep them in and see if we get reports from users of looping forever, and if not we can remove them in 8.1. we at CYGWIN had similar problems with windows locks on unlink. if unlink fails with ERROR_SHARING_VIOLATION or ERROR_ACCESS_DENIED, unlinking is deferred, put into a delqueue. we do no busy waiting then. it's done on exit. The most common problem is the delete on close semantics to handle removing a file which may be open. rename only fails on open files. we try first MoveFile, if that fails we try MoveFileEx MOVEFILE_REPLACE_EXISTING, but no loop on rename. http://sources.redhat.com/cgi-bin/cvsweb.cgi/src/winsup/cygwin/syscalls.cc?cvsroot=src http://sources.redhat.com/cgi-bin/cvsweb.cgi/src/winsup/cygwin/delqueue.cc?cvsroot=src -- Reini Urban http://xarch.tu-graz.ac.at/home/rurban/ ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] APR 1.0 released
Personally I don't think that any rename()-usleep loop is necessary. I'll check the archives. I agree the rename loop seems unnecessary. I kept it in case we hadn't dealt with all the failure places. Should we remove them now or wait for 8.1? Seems we should keep them in and see if we get reports from users of looping forever, and if not we can remove them in 8.1. What I do not understand is, that Windows has rename and _unlink. Are we using those or not? Looping forever is certainly not good, but I thought the current code had a limited loop. I think a limited loop is required, since both rename and _unlink can not cope with a locked file. Andreas ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] APR 1.0 released
Bruce Momjian wrote: Andrew Dunstan wrote: I'm not sure exactly what Bruce checked, so I just spent a few cycles making sure that we did not inadvertantly pick up a define of WIN32 from windows.h anywhere else. I *think* we are OK on that. However, ISTM this is a foot just waiting to be shot - in retrospect using WIN32 as our marker for native Windows, which we do in a great many places (around 300 by my count) was a less than stellar choice, given that it is defined by windows.h, and especially since we use that header for Cygwin as well as for Windows native in a few places. The use of WIN32 was because it usually does mean MinGW and Cygwin. But it doesn't. On MinGW WIN32 is a builtin compiler-defined value, and on Cygwin it isn't. To see this, do: touch empty.c; cpp -dM empty.c | grep WIN32 WIN32 *is* defined by windows.h, but in most cases we only include it if WIN32 is *already* defined. windows.h is included unconditionally in our win32.h, but again in most cases we only include that if WIN32 is already defined. So in most cases where we use it it isn't for Cygwin. But there are a few system include files on Cygwin that include it, so it's not guaranteed, although I don't think those affect us. We had lots of Cygwin-specific defines in there already so Win32 just means both Mingw and Cygwin. You will see only a few cases where we want Mingw and not Cygwin, but in those case we often also want MSVC and Borland, so it really is WIN32 ! __CYGWIN__. We do have one or two tests for __MINGW32__ where we really do want just that. Would you look around and see if this can be improved. I can't see any. As I said, I did look at all the include cases. That was based on the assumption that we actually wanted what I thought was the intention, namely that WIN32 was for Windows native only. If that's not the case we would need to review every one of the ~300 cases where WIN32 is used in #ifdef and friends. Bottom line - this is something of a mess. If we can make sure Cygwin isn't broken, we can probably live with what have for now. Personally, I would have configure work out something cleaner, like, say, defining WINDOWS_ALL for both Windows native and Cygwin. Then we could use that for cases meant to cover both, and __CYGWIN__ and __MINGW32__ for the specific cases, without worrying what the compiler and/or the system header files might have defined for us. cheers andrew ---(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] psql questions: SQL, progname, copyright dates
Robert Treat wrote: Ugh. If I want to see the syntax of my functions, I'd be forced to use the \df-+ syntax, and I'd argue people spend far more time wanting to see \df+ output on their own functions than they ever do on system functions. +1. I suspect Tom's use is pretty atypical. If I want to see a system function I usually name it. Otherwise I find myself doing \df public.*, which is usually after I have forgotten that that's what I need to do. cheers andrew ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] APR 1.0 released
Andrew Dunstan schrieb: Bruce Momjian wrote: Andrew Dunstan wrote: I'm not sure exactly what Bruce checked, so I just spent a few cycles making sure that we did not inadvertantly pick up a define of WIN32 from windows.h anywhere else. I *think* we are OK on that. However, ISTM this is a foot just waiting to be shot - in retrospect using WIN32 as our marker for native Windows, which we do in a great many places (around 300 by my count) was a less than stellar choice, given that it is defined by windows.h, and especially since we use that header for Cygwin as well as for Windows native in a few places. The use of WIN32 was because it usually does mean MinGW and Cygwin. But it doesn't. On MinGW WIN32 is a builtin compiler-defined value, and on Cygwin it isn't. To see this, do: touch empty.c; cpp -dM empty.c | grep WIN32 WIN32 *is* defined by windows.h, but in most cases we only include it if WIN32 is *already* defined. windows.h is included unconditionally in our win32.h, but again in most cases we only include that if WIN32 is already defined. So in most cases where we use it it isn't for Cygwin. But there are a few system include files on Cygwin that include it, so it's not guaranteed, although I don't think those affect us. We had lots of Cygwin-specific defines in there already so Win32 just means both Mingw and Cygwin. You will see only a few cases where we want Mingw and not Cygwin, but in those case we often also want MSVC and Borland, so it really is WIN32 ! __CYGWIN__. We do have one or two tests for __MINGW32__ where we really do want just that. Would you look around and see if this can be improved. I can't see any. As I said, I did look at all the include cases. That was based on the assumption that we actually wanted what I thought was the intention, namely that WIN32 was for Windows native only. If that's not the case we would need to review every one of the ~300 cases where WIN32 is used in #ifdef and friends. Bottom line - this is something of a mess. If we can make sure Cygwin isn't broken, we can probably live with what have for now. Personally, I would have configure work out something cleaner, like, say, defining WINDOWS_ALL for both Windows native and Cygwin. Then we could use that for cases meant to cover both, and __CYGWIN__ and __MINGW32__ for the specific cases, without worrying what the compiler and/or the system header files might have defined for us. Most of the ~300 cases are ok for CYGWIN. And probably for MINGW also. But I don't do MINGW countertests. I assume you do :) Just palloc misses some pending fixes for CYGWIN. cvs head didn't has this fixed. I'll come with a new patch to cvs HEAD soon. I'm quite busy with apache and php porting also. And I want to be careful not to break the FRONTEND section. At least beta2 needed this patch: --- postgresql-8.0.0beta2/src/include/utils/palloc.h.orig 2004-08-29 05:13:11.0 +0100 +++ postgresql-8.0.0beta2/src/include/utils/palloc.h 2004-09-03 14:03:50.279562100 +0100 @@ -80,7 +80,7 @@ #define pstrdup(str) MemoryContextStrdup(CurrentMemoryContext, (str)) -#ifdef WIN32 +#if defined(WIN32) || defined(__CYGWIN__) extern void *pgport_palloc(Size sz); extern char *pgport_pstrdup(const char *str); extern void pgport_pfree(void *pointer); -- Reini Urban http://xarch.tu-graz.ac.at/home/rurban/ ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] APR 1.0 released
Reini Urban wrote: Andrew Dunstan schrieb: We had lots of Cygwin-specific defines in there already so Win32 just means both Mingw and Cygwin. You will see only a few cases where we want Mingw and not Cygwin, but in those case we often also want MSVC and Borland, so it really is WIN32 ! __CYGWIN__. We do have one or two tests for __MINGW32__ where we really do want just that. Would you look around and see if this can be improved. I can't see any. As I said, I did look at all the include cases. That was based on the assumption that we actually wanted what I thought was the intention, namely that WIN32 was for Windows native only. If that's not the case we would need to review every one of the ~300 cases where WIN32 is used in #ifdef and friends. Bottom line - this is something of a mess. If we can make sure Cygwin isn't broken, we can probably live with what have for now. Personally, I would have configure work out something cleaner, like, say, defining WINDOWS_ALL for both Windows native and Cygwin. Then we could use that for cases meant to cover both, and __CYGWIN__ and __MINGW32__ for the specific cases, without worrying what the compiler and/or the system header files might have defined for us. Most of the ~300 cases are ok for CYGWIN. And probably for MINGW also. But I don't do MINGW countertests. I assume you do :) Cygwin is the likely point of failure here, since we know WIN32 is always defined on MinGW. cheers andrew ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] APR 1.0 released
Zeugswetter Andreas SB SD wrote: Personally I don't think that any rename()-usleep loop is necessary. I'll check the archives. I agree the rename loop seems unnecessary. I kept it in case we hadn't dealt with all the failure places. Should we remove them now or wait for 8.1? Seems we should keep them in and see if we get reports from users of looping forever, and if not we can remove them in 8.1. What I do not understand is, that Windows has rename and _unlink. Are we using those or not? Looping forever is certainly not good, but I thought the current code had a limited loop. I think a limited loop is required, since both rename and _unlink can not cope with a locked file. The current code prints a log message after 30 tries but keeps trying. We don't use the native ones because they don't work on open files properly. -- 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/docs/faqs/FAQ.html
Re: [HACKERS] APR 1.0 released
Andrew Dunstan [EMAIL PROTECTED] writes: Bottom line - this is something of a mess. If we can make sure Cygwin isn't broken, we can probably live with what have for now. Personally, I would have configure work out something cleaner, like, say, defining WINDOWS_ALL for both Windows native and Cygwin. Then we could use that for cases meant to cover both, and __CYGWIN__ and __MINGW32__ for the specific cases, without worrying what the compiler and/or the system header files might have defined for us. I agree that this is a good idea, partly because I do not care for the assumption that MINGW is the only compilation environment we'll ever support for the Windows-native port. I'm not in a position to work out or test the required changes, but I'll be happy to apply a patch if you do the legwork ... regards, tom lane ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] Failed assertion, CVS head
Grant Finnemore [EMAIL PROTECTED] writes: TRAP: FailedAssertion(!(((ntp)-t_data)-t_infomask 0x0010), File: catcache.c, Line: 1728) This seems moderately impossible :-(. Did you get a core dump? If so please provide a stack backtrace. regards, tom lane ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] APR 1.0 released
Tom Lane wrote: Andrew Dunstan [EMAIL PROTECTED] writes: Bottom line - this is something of a mess. If we can make sure Cygwin isn't broken, we can probably live with what have for now. Personally, I would have configure work out something cleaner, like, say, defining WINDOWS_ALL for both Windows native and Cygwin. Then we could use that for cases meant to cover both, and __CYGWIN__ and __MINGW32__ for the specific cases, without worrying what the compiler and/or the system header files might have defined for us. I agree that this is a good idea, partly because I do not care for the assumption that MINGW is the only compilation environment we'll ever support for the Windows-native port. I'm not in a position to work out or test the required changes, but I'll be happy to apply a patch if you do the legwork ... Too big a task for my current time budget :-( - currently my work does not involve any PostgreSQL component, and I am flat out delivering what I am paid for. Unless someone else steps up to the plate it will have to go on the TODO list. cheers andrew ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] row wise comparison broken
Yes, I found the following thread started by you in the pgsql-performance list: Subject: [PERFORM] best way to fetch next/prev record based on index Date: Tue, 27 Jul 2004 06:18:43 -0700 there were some concerns about backwards compatibility. IMO 8.0 is a good chance to fix it. Maybe we could add a GUC switch to fall back to pre-8.0 behavior... -- Tatsuo Ishii Here is a link to Tom's thoughts on possible approaches to implementing a fix, and why this is A Lot More Complicated Than It Seems (tm), particularly if taken to the next logical step where the planner could make use of the row-wise comparison to make more intelligent decisions about index selection. http://archives.postgresql.org/pgsql-performance/2004-07/msg00218.php Still, I think the current behavior is wrong...and is exactly the kind of trick question that a sql compliance benchmark might ask. Merlin ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] Failed assertion, CVS head
I'm afraid that I did not get a core dump. Sorry. My normal configure includes both debug and cassert - is there anything else I should set to ensure core dumps are generated? Regards, Grant Tom Lane wrote: Grant Finnemore [EMAIL PROTECTED] writes: TRAP: FailedAssertion(!(((ntp)-t_data)-t_infomask 0x0010), File: catcache.c, Line: 1728) This seems moderately impossible :-(. Did you get a core dump? If so please provide a stack backtrace. regards, tom lane ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED] ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] APR 1.0 released
Andrew Dunstan wrote: I agree that this is a good idea, partly because I do not care for the assumption that MINGW is the only compilation environment we'll ever support for the Windows-native port. I'm not in a position to work out or test the required changes, but I'll be happy to apply a patch if you do the legwork ... Too big a task for my current time budget :-( - currently my work does not involve any PostgreSQL component, and I am flat out delivering what I am paid for. I will do 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] APR 1.0 released
pgman wrote: Andrew Dunstan wrote: I think Bruce was mostly trying to make all the similar tests look alike. Also I agree that if a !b is clearer than if !b a; the latter requires a bit more thought to parse the extent of the ! operator... Right, just consistency. Ok. I understand now. I'm not sure exactly what Bruce checked, so I just spent a few cycles making sure that we did not inadvertantly pick up a define of WIN32 from windows.h anywhere else. I *think* we are OK on that. However, ISTM this is a foot just waiting to be shot - in retrospect using WIN32 as our marker for native Windows, which we do in a great many places (around 300 by my count) was a less than stellar choice, given that it is defined by windows.h, and especially since we use that header for Cygwin as well as for Windows native in a few places. The use of WIN32 was because it usually does mean MinGW and Cygwin. We had lots of Cygwin-specific defines in there already so Win32 just means both Mingw and Cygwin. You will see only a few cases where we want Mingw and not Cygwin, but in those case we often also want MSVC and Borland, so it really is WIN32 ! __CYGWIN__. We do have one or two tests for __MINGW32__ where we really do want just that. OK, I am wrong above. Coding assumes WIN32 is only for port named WIN32, which is mingw, and for BCC and VCC. I was not aware Cygwin defined it at all. Are we sure it does in a header file? I wonder if we should just call the port mingw and change the proper defines to __MINGW__. We would then create a define called WIN32_NATIVE that is defined for __MINGW__, BVC and VCC. -- 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] Failed assertion, CVS head
Grant Finnemore [EMAIL PROTECTED] writes: I'm afraid that I did not get a core dump. Sorry. My normal configure includes both debug and cassert - is there anything else I should set to ensure core dumps are generated? Check ulimit -c in the postmaster's environment. Personally I always put ulimit -c unlimited into the postmaster start script. regards, tom lane ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] APR 1.0 released
OK, change made. Thanks. --- Most of the ~300 cases are ok for CYGWIN. And probably for MINGW also. But I don't do MINGW countertests. I assume you do :) Just palloc misses some pending fixes for CYGWIN. cvs head didn't has this fixed. I'll come with a new patch to cvs HEAD soon. I'm quite busy with apache and php porting also. And I want to be careful not to break the FRONTEND section. At least beta2 needed this patch: --- postgresql-8.0.0beta2/src/include/utils/palloc.h.orig 2004-08-29 05:13:11.0 +0100 +++ postgresql-8.0.0beta2/src/include/utils/palloc.h 2004-09-03 14:03:50.279562100 +0100 @@ -80,7 +80,7 @@ #define pstrdup(str) MemoryContextStrdup(CurrentMemoryContext, (str)) -#ifdef WIN32 +#if defined(WIN32) || defined(__CYGWIN__) extern void *pgport_palloc(Size sz); extern char *pgport_pstrdup(const char *str); extern void pgport_pfree(void *pointer); -- Reini Urban http://xarch.tu-graz.ac.at/home/rurban/ ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/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 4: Don't 'kill -9' the postmaster
Re: [HACKERS] row wise comparison broken
Merlin Moncure [EMAIL PROTECTED] writes: http://archives.postgresql.org/pgsql-performance/2004-07/msg00218.php Still, I think the current behavior is wrong...and is exactly the kind of trick question that a sql compliance benchmark might ask. It undoubtedly is wrong. But it has been wrong forever, or at least since Tom Lockhart put in the syntax, back in 1997. We've gotten few complaints --- which means to me that this is not a high-priority bug fix. I think we should leave it as a to-do item for a future release cycle, rather than implement some hasty solution for 8.0. regards, tom lane ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] Failed assertion, CVS head
Ok, will do. Thanks. Tom Lane wrote: Grant Finnemore [EMAIL PROTECTED] writes: I'm afraid that I did not get a core dump. Sorry. My normal configure includes both debug and cassert - is there anything else I should set to ensure core dumps are generated? Check ulimit -c in the postmaster's environment. Personally I always put ulimit -c unlimited into the postmaster start script. ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] APR 1.0 released
Bruce Momjian wrote: OK, I am wrong above. Coding assumes WIN32 is only for port named WIN32, which is mingw, and for BCC and VCC. I was not aware Cygwin defined it at all. Are we sure it does in a header file? The problem is that some pieces of Cygwin code include windows.h, which it shouldn't do. If you fix those places, then there is no problem. I wonder if we should just call the port mingw and change the proper defines to __MINGW__. We would then create a define called WIN32_NATIVE that is defined for __MINGW__, BVC and VCC. WIN32 is the correct symbol; see above. -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] APR 1.0 released
Peter Eisentraut wrote: Bruce Momjian wrote: OK, I am wrong above. Coding assumes WIN32 is only for port named WIN32, which is mingw, and for BCC and VCC. I was not aware Cygwin defined it at all. Are we sure it does in a header file? The problem is that some pieces of Cygwin code include windows.h, which it shouldn't do. If you fix those places, then there is no problem. There are alot of windows.h includes: /include/port/win32.h:7:#include windows.h /port/crypt.c:56:#include windows.h /port/dirmod.c:45:#include windows.h /port/dirmod.c:405:#include windows.h /port/open.c:16:#include windows.h /port/sprompt.c:35:#include windows.h /timezone/zic.c:22:#include windows.h /utils/dllinit.c:44:#include windows.h /bin/pgevent/pgevent.c:15:#include windows.h /bin/psql/input.c:14:#include windows.h /bin/psql/mbprint.c:18:#include windows.h /bin/psql/startup.c:16:#include windows.h /interfaces/libpq/libpqdll.c:3:#include windows.h /interfaces/libpq/pthread-win32.c:14:#include windows.h /interfaces/libpq/win32.c:30:#include windows.h /backend/port/dynloader/win32.c:3:#include windows.h and I bet some of the system includes that we use call windows.h themselves. I wonder if we should just call the port mingw and change the proper defines to __MINGW__. We would then create a define called WIN32_NATIVE that is defined for __MINGW__, BVC and VCC. WIN32 is the correct symbol; see above. I hope you are right. -- 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] APR 1.0 released
Bruce Momjian wrote: There are alot of windows.h includes: ... and most of them are redundant because it is already included via c.h. -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(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] Making AFTER triggers act properly in PL functions
Stephan Szabo [EMAIL PROTECTED] writes: On Wed, 8 Sep 2004, Tom Lane wrote: It wouldn't quite work to use just transaction ID as the marker, since the inner SET CONSTRAINTS is very possibly done without using a subtransaction. But command ID or query nesting level or some such would work. I think the main concern here would be the space cost of adding still another field to the trigger records ... is it worth it? Would it be possible to basically alias the space for dte_done_xid to hold either the xid if it's done or the whatever if it's in progress? That's ugly, but it would presumably not increase the size of the record. I found a way to do this, which actually is to forget the done_xid field altogether and just store the firing ID number. Since firing ID increases monotonically throughout a transaction, all triggers fired during a given subtransaction will have IDs = the subtransaction-start- time ID counter. So we can clean up by looking for that, which is much faster than the TransactionId testing anyway. 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] APR 1.0 released
Peter Eisentraut wrote: Bruce Momjian wrote: There are alot of windows.h includes: ... and most of them are redundant because it is already included via c.h. Right, but we only include windows.h in Mingw. Does Cygwin need 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 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
[HACKERS] Update on Supporting Encryption in Postgresql
Thanks for the comments.
This piece will be a part of a bigger design and the problems
mentioned are very real. In the future, our goal is to design a database
system where the processing is done in a secure coprocessor(i.e no one
will be able to see what is inside) and
the small code inside the co-processor is verified using formal methods.
Therefore, all the problems you have mentioned will not be a issue for
our general case. We are even considering what could be revealed just
watching the disk access. Initial technical report can be found at
( http://www.cs.purdue.edu/homes/kanmurat/technical.ps).
Can you suggest me a solution to how to do
this on Postgresql backend?
I am asssuming that somewhere in the code, you are calling a function like
getPage(Page_id)
to retrieve the page(I am trying to change backend)
All I need to do is (I am not sure yet)
change such code with (ofcourse, I need to change writePage part)
getPage(Page_id)
{
ctr=Hash_Table(Page_id) //return somevalue needed for deccryption
Thread_Read(Page_id) // will call the original read code
Thread_Encryption.start(ctr, length);
when both threads are done finish the encryption
}
---(end of broadcast)---
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not match
Re: [HACKERS] Update on Supporting Encryption in Postgresql
On Fri, Sep 10, 2004 at 11:52:26AM -0500, Murat Kantarcioglu wrote:
Can you suggest me a solution to how to do
this on Postgresql backend?
I am asssuming that somewhere in the code, you are calling a function like
getPage(Page_id)
to retrieve the page(I am trying to change backend)
Probably the code you want to modify is in src/backend/storage/smgr.
Maybe you want to add a different storage manager (they are pluggable,
sort of).
getPage(Page_id)
{
ctr=Hash_Table(Page_id) //return somevalue needed for deccryption
Thread_Read(Page_id) // will call the original read code
Thread_Encryption.start(ctr, length);
when both threads are done finish the encryption
}
I think it would need extensive, painful and unwelcome modifications to
use threads to do the job. You could just as well do it sequentially,
like in
encryptedPage = getPage(page_id);
clearPage = unencrypt(encryptedPage);
return clearPage;
And the reverse for storage. This may only need modifications to
mdread() and mdwrite() ... unless your encryption scheme returns a
different length than the original.
--
Alvaro Herrera (alvherre[a]dcc.uchile.cl)
Estoy de acuerdo contigo en que la verdad absoluta no existe...
El problema es que la mentira sà existe y tu estás mintiendo (G. Lama)
---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] more dirmod CYGWIN
Reini Urban schrieb: [BTW: there's no need to cc all, I'm subscribed to most lists] Reini Urban schrieb: Bruce Momjian schrieb: Andrew Dunstan wrote: Reini Urban wrote: FYI: WIN32 is also defined because windows.h is included. (/usr/incluse/w32api/windef.h) If you want this or that, do proper nesting, and use #else. Ugh, yes. A little experimentation shows that __WIN32__ is defined for MinGW only, but WIN32 is for both. I wonder how we missed that in various places. Maybe we need a little audit of the use of WIN32. OK, fixed. We should not be using __WIN32__, just Win32. The proper test is #ifndef __CYGWIN__. very good. just think of future MSVC versions. Just one more glitch: #undef rename #undef unlink has to be defined before #include unistd.h on CYGWIN, because unistd.h has the declarations for rename and unlink, which are required inside the pg versions. without the #undef, the macros which rename rename to pgrename, ... are still effective, which will lead to undeclared/falsely autodeclared rename/unlink parts. I don't know for mingw, if they need the pgrename/pgunlink declaration. For my CYGWIN patch I moved those two lines before #include unistd.h. FYI: latest cvs HEAD, without any patches. make runs now through with the expected implicit declaration warnings, but without any errors. Esp. the CYGWIN-specific SHMLIB linking errors are now gone. good! make[2]: Entering directory `/usr/src/postgresql/pgsql/src/port' gcc -O2 -fno-strict-aliasing -Wall -Wmissing-prototypes -Wmissing-declarations -I../../src/port -I../../src/include -c -o dirmod.o dirmod.c dirmod.c: In Funktion pgunlink: dirmod.c:113: Warnung: implicit declaration of function `unlink' dirmod.c: In Funktion rmt_cleanup: dirmod.c:267: Warnung: implicit declaration of function `pgport_pfree' dirmod.c: In Funktion rmtree: dirmod.c:318: Warnung: implicit declaration of function `pgport_palloc' dirmod.c:318: Warnung: Zuweisung erzeugt Zeiger von Ganzzahl ohne Typkonvertierung dirmod.c:333: Warnung: implicit declaration of function `pgport_pstrdup' dirmod.c:333: Warnung: Zuweisung erzeugt Zeiger von Ganzzahl ohne Typkonvertierung make check hangs at: running on port 65432 with pid 2304 == creating database regression == CREATE DATABASE ALTER DATABASE == dropping regression test user accounts == == installing PL/pgSQL== == running regression test queries== parallel group (13 tests): int2 int4 int8 float4 name varchar numeric which means rename works ok. probably the false implicit declarations in the memory code break it. I'll come with another patch later. parallel tests hang on cygwin. this is expected. attached is the postmaster stackdump on the parallel test (if you care), and the IPC's during the parallel test (not quite busy...): $ ipcs Message Queues: T ID KEYMODE OWNERGROUP Shared Memory: T ID KEYMODE OWNERGROUP m 1966080 65432001 --rw--- rurban root Semaphores: T ID KEYMODE OWNERGROUP s 1966080 65432001 --rw--- rurban root s 1966081 65432002 --rw--- rurban root s 1966082 65432003 --rw--- rurban root s 1966083 65432004 --rw--- rurban root s 1966084 65432005 --rw--- rurban root s 1966085 65432006 --rw--- rurban root s 1966086 65432007 --rw--- rurban root with the serial schedule all tests but the last pass. test tablespace ... FAILED This is the tail of the postmaster log for this failing test. ERROR: cannot alter table fullname because column people.fn uses its rowtype ERROR: could not create symbolic link /usr/src/postgresql/pgsql/src/test/regress/./tmp_check/data/pg_tblspc/155118: No error ERROR: tablespace testspace does not exist ERROR: schema testschema does not exist ERROR: schema testschema does not exist ERROR: schema testschema does not exist ERROR: schema testschema does not exist ERROR: could not set permissions on directory /no/such/location: No such file or directory ERROR: tablespace nosuchspace does not exist ERROR: tablespace testspace does not exist ERROR: schema testschema does not exist ERROR: tablespace testspace does not exist LOG: received smart shutdown request LOG: shutting down LOG: database system is shut down attached is the regression.diffs, and also the overall patch against current CVS HEAD I used for this run. (the move-#undef patch is probably already applied regarding bruce) this should be applied. -- Reini Urban http://xarch.tu-graz.ac.at/home/rurban/ *** ./expected/tablespace.out Fri Sep 10 13:42:08 2004 --- ./results/tablespace.outFri Sep 10 13:53:22 2004 *** *** 1,34 -- create a tablespace we can use CREATE
Re: [HACKERS] more dirmod CYGWIN
I have applied all parts of your patch now. --- Reini Urban wrote: Reini Urban schrieb: [BTW: there's no need to cc all, I'm subscribed to most lists] Reini Urban schrieb: Bruce Momjian schrieb: Andrew Dunstan wrote: Reini Urban wrote: FYI: WIN32 is also defined because windows.h is included. (/usr/incluse/w32api/windef.h) If you want this or that, do proper nesting, and use #else. Ugh, yes. A little experimentation shows that __WIN32__ is defined for MinGW only, but WIN32 is for both. I wonder how we missed that in various places. Maybe we need a little audit of the use of WIN32. OK, fixed. We should not be using __WIN32__, just Win32. The proper test is #ifndef __CYGWIN__. very good. just think of future MSVC versions. Just one more glitch: #undef rename #undef unlink has to be defined before #include unistd.h on CYGWIN, because unistd.h has the declarations for rename and unlink, which are required inside the pg versions. without the #undef, the macros which rename rename to pgrename, ... are still effective, which will lead to undeclared/falsely autodeclared rename/unlink parts. I don't know for mingw, if they need the pgrename/pgunlink declaration. For my CYGWIN patch I moved those two lines before #include unistd.h. FYI: latest cvs HEAD, without any patches. make runs now through with the expected implicit declaration warnings, but without any errors. Esp. the CYGWIN-specific SHMLIB linking errors are now gone. good! make[2]: Entering directory `/usr/src/postgresql/pgsql/src/port' gcc -O2 -fno-strict-aliasing -Wall -Wmissing-prototypes -Wmissing-declarations -I../../src/port -I../../src/include -c -o dirmod.o dirmod.c dirmod.c: In Funktion pgunlink: dirmod.c:113: Warnung: implicit declaration of function `unlink' dirmod.c: In Funktion rmt_cleanup: dirmod.c:267: Warnung: implicit declaration of function `pgport_pfree' dirmod.c: In Funktion rmtree: dirmod.c:318: Warnung: implicit declaration of function `pgport_palloc' dirmod.c:318: Warnung: Zuweisung erzeugt Zeiger von Ganzzahl ohne Typkonvertierung dirmod.c:333: Warnung: implicit declaration of function `pgport_pstrdup' dirmod.c:333: Warnung: Zuweisung erzeugt Zeiger von Ganzzahl ohne Typkonvertierung make check hangs at: running on port 65432 with pid 2304 == creating database regression == CREATE DATABASE ALTER DATABASE == dropping regression test user accounts == == installing PL/pgSQL== == running regression test queries== parallel group (13 tests): int2 int4 int8 float4 name varchar numeric which means rename works ok. probably the false implicit declarations in the memory code break it. I'll come with another patch later. parallel tests hang on cygwin. this is expected. attached is the postmaster stackdump on the parallel test (if you care), and the IPC's during the parallel test (not quite busy...): $ ipcs Message Queues: T ID KEYMODE OWNERGROUP Shared Memory: T ID KEYMODE OWNERGROUP m 1966080 65432001 --rw--- rurban root Semaphores: T ID KEYMODE OWNERGROUP s 1966080 65432001 --rw--- rurban root s 1966081 65432002 --rw--- rurban root s 1966082 65432003 --rw--- rurban root s 1966083 65432004 --rw--- rurban root s 1966084 65432005 --rw--- rurban root s 1966085 65432006 --rw--- rurban root s 1966086 65432007 --rw--- rurban root with the serial schedule all tests but the last pass. test tablespace ... FAILED This is the tail of the postmaster log for this failing test. ERROR: cannot alter table fullname because column people.fn uses its rowtype ERROR: could not create symbolic link /usr/src/postgresql/pgsql/src/test/regress/./tmp_check/data/pg_tblspc/155118: No error ERROR: tablespace testspace does not exist ERROR: schema testschema does not exist ERROR: schema testschema does not exist ERROR: schema testschema does not exist ERROR: schema testschema does not exist ERROR: could not set permissions on directory /no/such/location: No such file or directory ERROR: tablespace nosuchspace does not exist ERROR: tablespace testspace does not exist ERROR: schema testschema does not exist ERROR: tablespace testspace does not exist LOG: received smart shutdown request LOG: shutting down LOG: database system is shut down attached is the regression.diffs, and also the overall patch against current CVS HEAD I used for this
Re: [HACKERS] more dirmod CYGWIN
Bruce Momjian schrieb: I have applied all parts of your patch now. Thanks. Core builds and works fine now. (plperl IPC problems aside) But there's are still some more minor SHLIB glitches, which only affects contrib, because -lpgport is missing for various dll's. SHLIB_LINK doesn't contain the libs only the paths, because they are filtered out somewhere. But first I want to find the real cause of the problem. Maybe LIB is just missing a -lpgport. $ diff -bu src/Makefile.shlib.orig src/Makefile.shlib --- src/Makefile.shlib.orig 2004-09-03 00:06:43.0 +0100 +++ src/Makefile.shlib 2004-09-10 17:12:18.528655500 +0100 @@ -216,6 +216,7 @@ ifeq ($(PORTNAME), cygwin) shlib= $(NAME)$(DLSUFFIX) + SHLIB_LINK += -lpgport endif ifeq ($(PORTNAME), win32) $ diff -bu src/makefiles/pgxs.mk.orig src/makefiles/pgxs.mk --- src/makefiles/pgxs.mk.orig 2004-07-30 13:26:40.0 +0100 +++ src/makefiles/pgxs.mk 2004-09-10 17:09:15.499748300 +0100 @@ -63,7 +63,11 @@ ifdef MODULES override CFLAGS += $(CFLAGS_SL) -SHLIB_LINK += $(BE_DLLLIBS) +ifeq ($(PORTNAME), cygwin) + SHLIB_LINK += $(BE_DLLLIBS) $(LDFLAGS) $(LIBS) -lpgport +else + SHLIB_LINK += $(BE_DLLLIBS) +endif endif ifdef PG_CPPFLAGS -- Reini Urban http://xarch.tu-graz.ac.at/home/rurban/ ---(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] APR 1.0 released
Bruce Momjian schrieb: Peter Eisentraut wrote: Bruce Momjian wrote: There are alot of windows.h includes: ... and most of them are redundant because it is already included via c.h. Right, but we only include windows.h in Mingw. Does Cygwin need it? Not really, but it will be lot of new work, which is imho not worth it. In some places the cygwin section calls WinAPI functions. It could be worked around by using the posix/cygwin counterparts. pgsymlink for example. -- Reini Urban http://xarch.tu-graz.ac.at/home/rurban/ ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] APR 1.0 released
Reini Urban wrote: Bruce Momjian schrieb: Peter Eisentraut wrote: Bruce Momjian wrote: There are alot of windows.h includes: ... and most of them are redundant because it is already included via c.h. Right, but we only include windows.h in Mingw. Does Cygwin need it? Not really, but it will be lot of new work, which is imho not worth it. In some places the cygwin section calls WinAPI functions. It could be worked around by using the posix/cygwin counterparts. pgsymlink for example. I'm quite certain we can avoid the problem if we are careful. But wouldn't it be better to get rid of the problem instead by using some other marker? cheers andrew ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Making AFTER triggers act properly in PL functions
Stephan Szabo [EMAIL PROTECTED] writes: On Wed, 8 Sep 2004, Tom Lane wrote: Yeah, I had come to the same conclusion after more thought. But we could certainly aggregate all the similar events generated by a single query into a common status structure. Definately. The ~20 byte/row gain for large updates/insert/delete is worth it. I think it'd actually increase the size for the single row case since we'd have the pointer to deal with (we could use a flag that tells us whether this item actually has a pointer to a shared status structure or just contains the status structure but that seems kinda ugly). I have given up on this idea for the moment, as on further examination it seems to require a lot of work to get any improvement. The code I just committed uses a 32-byte (on 32-bit machines anyway) data structure for each trigger event. Allowing for palloc overhead, that's 40 bytes per event. If we separated it into two parts, the per-tuple part would still need 20 bytes per event (a list link pointer, a link to the shared part, and 2 tuple item pointers). Because palloc would round such a requested size up to the next power of 2, there would actually be no savings at all, unless we were willing to hack up palloc to have a special case for this request size. Which is not beyond the realm of reason, certainly, but even with no round-up the effective space requirement would be 28 bytes. Doing a lot of work to get from 40 to 28 bytes doesn't excite me. I spent some time thinking about whether the per-tuple stuff could be kept in large arrays, so that we eliminate both the list links and the palloc overhead, bringing it down to 16 bytes per event. This would be enough savings to be worth some trouble, but the management seems really messy, mainly because retail deletion of fired events isn't easy anymore. I decided trying to get this done for 8.0 wasn't going to be practical. Possibly someone will take another look in a future release cycle. regards, tom lane ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Update on Supporting Encryption in Postgresql
Murat Kantarcioglu [EMAIL PROTECTED] writes: This piece will be a part of a bigger design and the problems mentioned are very real. In the future, our goal is to design a database system where the processing is done in a secure coprocessor(i.e no one will be able to see what is inside) and the small code inside the co-processor is verified using formal methods. [ raised eyebrow... ] You think a SQL database is small code you can verify using formal methods? I don't really see how you can expect that the decrypted data can be held entirely within a small secured area and still get any useful work done. 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] Update on Supporting Encryption in Postgresql
Our basic claim is to be able to do most of the encryption while we are
reading the page. That is the reason I need the threads. Any suggestion
about the threads are welcome. Thanks.
Murat
Alvaro Herrera wrote:
On Fri, Sep 10, 2004 at 11:52:26AM -0500, Murat Kantarcioglu wrote:
Can you suggest me a solution to how to do
this on Postgresql backend?
I am asssuming that somewhere in the code, you are calling a function like
getPage(Page_id)
to retrieve the page(I am trying to change backend)
Probably the code you want to modify is in src/backend/storage/smgr.
Maybe you want to add a different storage manager (they are pluggable,
sort of).
getPage(Page_id)
{
ctr=Hash_Table(Page_id) //return somevalue needed for deccryption
Thread_Read(Page_id) // will call the original read code
Thread_Encryption.start(ctr, length);
when both threads are done finish the encryption
}
I think it would need extensive, painful and unwelcome modifications to
use threads to do the job. You could just as well do it sequentially,
like in
encryptedPage = getPage(page_id);
clearPage = unencrypt(encryptedPage);
return clearPage;
And the reverse for storage. This may only need modifications to
mdread() and mdwrite() ... unless your encryption scheme returns a
different length than the original.
---(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] Update on Supporting Encryption in Postgresql
It is really hard to describe all the project in few e-mails. Obviously, we will not try to run entire database software in that secure hardware. Also memory limitations are not important. For example, please check the research on oblivious RAM to see even small memory on such hardware can be leveraged to execute programs with huge memory requirements. Also please check the Practical Private Information Retrieval work to see how such hardware is used for solving PIR problem. Anyway, I totaly understand your reservations but we are trying to have a solution to answer your concerns and much more. Thanks for the interest. Murat Tom Lane wrote: Murat Kantarcioglu [EMAIL PROTECTED] writes: This piece will be a part of a bigger design and the problems mentioned are very real. In the future, our goal is to design a database system where the processing is done in a secure coprocessor(i.e no one will be able to see what is inside) and the small code inside the co-processor is verified using formal methods. [ raised eyebrow... ] You think a SQL database is small code you can verify using formal methods? I don't really see how you can expect that the decrypted data can be held entirely within a small secured area and still get any useful work done. 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]) ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] APR 1.0 released
Andrew Dunstan wrote: Reini Urban wrote: Bruce Momjian schrieb: Peter Eisentraut wrote: Bruce Momjian wrote: There are alot of windows.h includes: ... and most of them are redundant because it is already included via c.h. Right, but we only include windows.h in Mingw. Does Cygwin need it? Not really, but it will be lot of new work, which is imho not worth it. In some places the cygwin section calls WinAPI functions. It could be worked around by using the posix/cygwin counterparts. pgsymlink for example. I'm quite certain we can avoid the problem if we are careful. But wouldn't it be better to get rid of the problem instead by using some other marker? Agreed. We would never be sure we got them all and new ones didn't get added in over time. -- 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] more dirmod CYGWIN
Well, glad we are on to real Cygwin issues at least. I know I had probably broken Cygwin with all the Win32 changes. I actually thought it would be worse. Glad you were able to help us. On the /contrib issue, I am not sure we even have Mingw compiling contrib. What error are you seeing? If I try to compile /contrib/dbsize under Unix I don't see any -lpgport line in the compile: $ cd /pgtop/contrib/dbsize/ $ gmake sed 's,MODULE_PATHNAME,$libdir/dbsize,g' dbsize.sql.in dbsize.sql gcc -O2 -fno-strict-aliasing -Wall -Wmissing-prototypes -Wmissing-declarations -O1 -Wall -Wmissing-prototypes -Wmissing-declarations -Wpointer-arith -Wcast-align -fpic -I. -I../../src/include -I/usr/local/include/readline -I/usr/contrib/include -c -o dbsize.o dbsize.c gcc -shared -o dbsize.so dbsize.o rm dbsize.o Let me add that I think the whole FRONTEND flags for /port are a hack and might need to be change before we hit 8.0 final. They are _very_ fragile but I have not thought of a good solution yet. It is actually on the open items list. --- Reini Urban wrote: Bruce Momjian schrieb: I have applied all parts of your patch now. Thanks. Core builds and works fine now. (plperl IPC problems aside) But there's are still some more minor SHLIB glitches, which only affects contrib, because -lpgport is missing for various dll's. SHLIB_LINK doesn't contain the libs only the paths, because they are filtered out somewhere. But first I want to find the real cause of the problem. Maybe LIB is just missing a -lpgport. $ diff -bu src/Makefile.shlib.orig src/Makefile.shlib --- src/Makefile.shlib.orig 2004-09-03 00:06:43.0 +0100 +++ src/Makefile.shlib 2004-09-10 17:12:18.528655500 +0100 @@ -216,6 +216,7 @@ ifeq ($(PORTNAME), cygwin) shlib= $(NAME)$(DLSUFFIX) + SHLIB_LINK += -lpgport endif ifeq ($(PORTNAME), win32) $ diff -bu src/makefiles/pgxs.mk.orig src/makefiles/pgxs.mk --- src/makefiles/pgxs.mk.orig 2004-07-30 13:26:40.0 +0100 +++ src/makefiles/pgxs.mk 2004-09-10 17:09:15.499748300 +0100 @@ -63,7 +63,11 @@ ifdef MODULES override CFLAGS += $(CFLAGS_SL) -SHLIB_LINK += $(BE_DLLLIBS) +ifeq ($(PORTNAME), cygwin) + SHLIB_LINK += $(BE_DLLLIBS) $(LDFLAGS) $(LIBS) -lpgport +else + SHLIB_LINK += $(BE_DLLLIBS) +endif endif ifdef PG_CPPFLAGS -- Reini Urban http://xarch.tu-graz.ac.at/home/rurban/ ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED]) -- 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/docs/faqs/FAQ.html
Re: [pgsql-hackers-win32] [HACKERS] more dirmod CYGWIN
Bruce Momjian [EMAIL PROTECTED] writes: On the /contrib issue, I am not sure we even have Mingw compiling contrib. We don't --- apparently the win32 crowd hadn't bothered to try it until recently. There are a couple of patches in the queue that claim to make individual modules work, but I dunno what the overall situation is. regards, tom lane ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] SELECT FOR UPDATE NOWAIT and PostgreSQL 8.0
Devrim GUNDUZ wrote:
[ PGP not available, raw data follows ]
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi,
AFAIR there was a thread about SELECT FOR UPDATE NOWAIT availability in
{7.5,8.0}, 7-8 months ago.
Now we have LOCK TABLE ... NOWAIT; but I wonder whether we'll have the
SELECT ... NOWAIT one. Today I got a request for this; and it was
reported that this feature will be used in a huge project.
If there is an unapplied patch that I've missed (even though I didn't see
one in http://momjian.postgresql.org/cgi-bin/pgpatches2), I'd like to
know it -- taking all the risks, surely.
I don't know of any patch done. The solution suggested was to use
statement_timeout before the SELECT FOR UPDATE. I am not 100% excited
about that because there is no way to know if the query is slow because
of a lock or just system slowness, but the logic is that you really
don't care why you have failed to do a lock or not, just that the query
is taking a long time. It does solve the problem and allow us to not
add NOWAIT to UPDATE and DELETE too. The other problem is that queries
do a lot of locking (think system tables) so there is no way to know
which locks we shouldn't wait for. At last LOCK specifies the object,
but of course it doesn't do row-level control.
Care to suggest an FAQ.
--
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] more dirmod CYGWIN
Bruce Momjian wrote: On the /contrib issue, I am not sure we even have Mingw compiling contrib. What error are you seeing? If I try to compile /contrib/dbsize under Unix I don't see any -lpgport line in the compile: It doesn't need any. It's loaded in the backend, which already has libpgport. -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] APR 1.0 released
Bruce Momjian wrote: Peter Eisentraut wrote: Bruce Momjian wrote: There are alot of windows.h includes: ... and most of them are redundant because it is already included via c.h. Right, but we only include windows.h in Mingw. That has nothing to do with my point. Does Cygwin need it? No, except in well-controlled circumstances. -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(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] tablespace question ... pg vs oracle
Marc G. Fournier wrote: I have someone that is asking if you can recover some tablespaces in a database, but leave the others online ... apparently its a feature of tablespaces under Oracle ... I could see it for schemas, but sounds like it could cause problems depeending on how you are using tablespaces ... You can not. The tablespace is not an independent entity. I doubt we would ever suppor that. I suppose if the entire database was in a specific schema you could recover that but you would have to adjust the shared system tables perhaps. -- 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] x86_64 configure problem
Gaetano Mendola wrote:
Joe Conway wrote:
# python -c from distutils.sysconfig import get_python_lib as f;
import os; print
os.path.join(f(plat_specific=1,standard_lib=1),'config')
/usr/lib64/python2.3/config
Any other proposals? If not, any objections to the attached patch?
No one, we have to check also for the presence of distutils package
installation.
It's not installed by default and I was bitten by it during the RPM
building for
RH AS 2.1
What version of python comes with RH2.1?
In any case, the online documentation for python suggests that it is
reasonable to expect that distutils is already installed (by default for
python = 1.6, and by the user for python 1.5.2). See:
http://www.python.org/doc/2.2.3/dist/intro.html
If there are no other objections, I'll commit the attached in about 24
hours.
Thanks,
Joe
Index: config/python.m4
===
RCS file: /cvsroot/pgsql-server/config/python.m4,v
retrieving revision 1.7
diff -c -r1.7 python.m4
*** config/python.m4 29 Nov 2003 19:51:17 - 1.7
--- config/python.m4 10 Sep 2004 22:15:38 -
***
*** 25,31
python_version=`${PYTHON} -c import sys; print sys.version[[:3]]`
python_prefix=`${PYTHON} -c import sys; print sys.prefix`
python_execprefix=`${PYTHON} -c import sys; print sys.exec_prefix`
! python_configdir=${python_execprefix}/lib/python${python_version}/config
python_includespec=-I${python_prefix}/include/python${python_version}
if test $python_prefix != $python_execprefix; then
python_includespec=-I${python_execprefix}/include/python${python_version} $python_includespec
--- 25,31
python_version=`${PYTHON} -c import sys; print sys.version[[:3]]`
python_prefix=`${PYTHON} -c import sys; print sys.prefix`
python_execprefix=`${PYTHON} -c import sys; print sys.exec_prefix`
! python_configdir=`${PYTHON} -c from distutils.sysconfig import get_python_lib as f; import os; print os.path.join(f(plat_specific=1,standard_lib=1),'config')`
python_includespec=-I${python_prefix}/include/python${python_version}
if test $python_prefix != $python_execprefix; then
python_includespec=-I${python_execprefix}/include/python${python_version} $python_includespec
---(end of broadcast)---
TIP 6: Have you searched our list archives?
http://archives.postgresql.org
Re: [HACKERS] APR 1.0 released
Peter Eisentraut wrote: Bruce Momjian wrote: Peter Eisentraut wrote: Bruce Momjian wrote: There are alot of windows.h includes: ... and most of them are redundant because it is already included via c.h. Right, but we only include windows.h in Mingw. That has nothing to do with my point. Does Cygwin need it? No, except in well-controlled circumstances. OK, so should we remove the redundant windows.h calls and see what happens? They are testing on WIN32 anyway so I don't even see how Cygwin would be hitting them. -- 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] more dirmod CYGWIN
Peter Eisentraut wrote: Bruce Momjian wrote: On the /contrib issue, I am not sure we even have Mingw compiling contrib. What error are you seeing? If I try to compile /contrib/dbsize under Unix I don't see any -lpgport line in the compile: It doesn't need any. It's loaded in the backend, which already has libpgport. Ah, very tricky. Thanks. But waht about command-line tools in /contrib? Maybe they are OK because I didn't see any fixes like that in the new patches we received. Thanks. -- 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 8: explain analyze is your friend
[HACKERS] Caught up on email
OK, I am caught up on email now after five days of travel. I have loaded the patch queue for others to empty. Two weeks to go. -- 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] Developers page is down
Centuries ago, Nostradamus foresaw when [EMAIL PROTECTED] (Jaime Casanova) would write: By the way, will be a way in postgresql 8 to add a column in a middle of a table. just curious. What do you mean by in a middle of a table? A relation is simply a set of attributes that _don't_ forcibly have an order, because sets are unordered. -- output = reverse(gro.gultn @ enworbbc) http://cbbrowne.com/info/nonrdbms.html What we need is either less corruption, or more chance to participate in it. -- Unknown ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] AIX and v8 beta1
[EMAIL PROTECTED] (Rod Taylor) writes: On Sun, 2004-09-05 at 13:43, Tom Lane wrote: Rod Taylor [EMAIL PROTECTED] writes: collect2: ld returned 254 exit status That's a fairly unhelpful error message, isn't it? I'm thinking that this may be due to having added the timezone library to the backend link, but I really don't see just how. Afraid you're on your own to identify the cause :-( I no longer have access to this machine (trial at an IBM Innovation Centre), so it'll have to be up to someone else to look at. We've got a number of AIX boxes over at Afilias, so we'll definitely get around to this at some point. (Probably not this week, is all...) -- output = reverse(moc.enworbbc @ enworbbc) http://cbbrowne.com/info/multiplexor.html In MDDT, no one can hear you scream... But everybody can hear you say whoops! ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
[HACKERS] Adding columns in the middle (Was: Developers page is down)
On Sep 4, 2004, at 10:07 PM, Christopher Browne wrote: Centuries ago, Nostradamus foresaw when [EMAIL PROTECTED] (Jaime Casanova) would write: By the way, will be a way in postgresql 8 to add a column in a middle of a table. just curious. What do you mean by in a middle of a table? A relation is simply a set of attributes that _don't_ forcibly have an order, because sets are unordered. In the SQL spec, columns are ordered, iirc, as sad as that is. Writing application code that depends on column order is asking for pain and suffering. Michael Glaesemann grzm myrealbox com ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
[HACKERS] Help with check_pqsql PLUGIN!
Hello, Hackers! I use Nagios monitoring system. Can you help, please? I want to compile plugin for Nagios named check_pqsql. Which libraries I need to compile it successful? Thank you.
Re: [HACKERS] Indexed views?
Greg Stark wrote: Doug McNaught [EMAIL PROTECTED] writes: Short answer: MVCC tuple visibility status isn't (and can't be) stored in the index. Well the can't part is false or at least unproven. From prior discussion the only thing that would be technically challenging would be avoiding deadlocks. Rather than yank the MVCC visibility around, how about a (relatively small) change to the query plan ... I take it that it is a very reasonable assumption that only a small proportion of index records are actually invalid (else Yurk why use the index?). In that case, how about tacking the heap table row ptr onto result tuples, and letting them percolate up through the tree? Since you're using an index at all, the planner must be expecting a restricted set of rows to make it up through to the root. If there is any filter criteria against the values from the index rows, you won't even have to check rows for tuple visibility, that don't pass that filter. As soon as you rise to a point where (index) rows will either be multiplied (a join) or combined (a group-by/distinct), you can validate them against the heap file in relatively large batches, with a hash caching of which ones have been checked for visibility. Just a thought. ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] Making AFTER triggers act properly in PL functions
I wrote: Actually, I'd really like to get it back down to the 7.4 size, which was already too big :-(. That might be a vain hope though. As long as we're talking about hack-slash-and-burn on this data structure ... The cases where people get annoyed by the size of the deferred trigger list are nearly always cases where the exact same trigger is to be fired on a large number of tuples from the same relation (ie, we're doing a mass INSERT, mass UPDATE, etc). Since it's the exact same trigger, all these events must have identical deferrability properties, and will all be fired (or not fired) at the same points. So it seems to me that we could refactor the data structure into some per-trigger stuff (tgoid, relid, xid, flag bits) associated with an array of per-event records that hold only the old/new ctid fields, and get it down to about 12 bytes per tuple instead of forty-some. However this would lose the current properties concerning event firing order. Could we do something where each event stores just a pointer to some per-trigger data (shared across all like events) plus the old and new ctid fields? 16 bytes is still way better than 44. Thoughts? Am I missing some reason why we could not share status data across multiple tuples, if their events are otherwise identical? If we fail partway through processing the trigger events, I don't see that we care exactly where. regards, tom lane ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
[HACKERS] Plannings on Implementation of DECLARE CURSOR x for SELECT ... FOR UPDATE / UPDATE ... WHERE CURRENT OF ...
Hi, are you planning to implement WRITABLE cursors in one of the next releases of pgsql? If so, do you have some kind of roadmap about that? We are currently looking for a replacement rdbms for an informix based application with a duty of over 100 concurrent interactive user sessions. Therefore we require the row-locking mechanism of DECLARE CURSOR x FRO SELECT FOR UPDATE and UPDATE ... WHERE CURRENT OF ... Tnx for your answer in advance, Dr. Hans Groschwitz www.boom.de ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Making AFTER triggers act properly in PL functions
On Wed, 8 Sep 2004, Tom Lane wrote: I wrote: Actually, I'd really like to get it back down to the 7.4 size, which was already too big :-(. That might be a vain hope though. As long as we're talking about hack-slash-and-burn on this data structure ... The cases where people get annoyed by the size of the deferred trigger list are nearly always cases where the exact same trigger is to be fired on a large number of tuples from the same relation (ie, we're doing a mass INSERT, mass UPDATE, etc). Since it's the exact same trigger, all these events must have identical deferrability properties, and will all be fired (or not fired) at the same points. So it seems to me that we could refactor the data structure into some per-trigger stuff (tgoid, relid, xid, flag bits) associated with an array of per-event records that hold only the old/new ctid fields, and get it down to about 12 bytes per tuple instead of forty-some. However this would lose the current properties concerning event firing order. Could we do something where each event stores just a pointer to some per-trigger data (shared across all like events) plus the old and new ctid fields? 16 bytes is still way better than 44. Something like the main items being: - next pointer for list - old ctid - new ctid - pointer to other information with other information: - event - relid, - done xid - n_items - dte_item array Where the OtherInformation could be shared within the statement (for identical events)? I think it'd be problematic to try sharing between statements. But, I'm sort of assuming the following are true: Once a group of items is marked to be run, all items will run even if set constraints ... deferred happens while the run occurs. If set constraints is called inside a function used in a statement (like update foo set bar=f(baz) where f() calls set constraints) the entire queue runs with one particular deferrability. If an error occurs, either the entire set of event objects for the statement are going away because they're new, or if it was something run from set constraints we're going to want to rerun the entire set anyway. ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] Supporting Encryption in Postgresql
Centuries ago, Nostradamus foresaw when Murat Kantarcioglu [EMAIL PROTECTED] would write: For our research project, I need to implement an encryption support for Postgressql. At this current phase, I need to at least support page level encryption In other words, each page that belongs to a certain sensitive table will be stored encrypted on the harddisk. Since we are trying to have a new design that can start the decryption before even we see the data, I need to have some kind of thread support. My questions are in order to support page level encryption(i,e encrypt each page before writing back to disk and decrypt each page after we read from disk.) which parts of the code should be changed? Our more simply, is /src/backend/storage/smgr/md.c the only code that does the disk access? Since our design requires thread support (we will do some of the decryption, before we see the data, therefore during disk access, we need to continue decryption) Can you suggest me a good thread lib you think will work fine with postgresql ? Thanks for your help. You'd better step back to your threat model, and figure out what encryption will actually get you. I don't see any reason to think that you can actually gain _anything_ from page level encryption. If you think you do, then you ought to either: a) Show how you gain it using something like Linux's capability to use encrypted loopback filesystems, which would not require touching PostgreSQL at all, or b) Demonstrate what are the attacks that page level encryption would protect against, and how. The problem with any such mechanisms is essentially the same, namely that the encryption key has got to sit in memory in either the database server process or in the kernel's memory. As such, the key is vulnerable to anyone with root access that can access /proc or its equivalent and get at process memory. The only way for the encryption key NOT to be vulnerable in this fashion is if the encryption key is communicated neither to the database server nor to the OS kernel. I'd suggest you avail yourself of the book _Translucent Databases_ by Peter Weyner; it involves a model where the database engine is not entrusted with cryptography at all. Instead, cryptography is all done within the client. -- (reverse (concatenate 'string gro.gultn @ enworbbc)) http://www.ntlug.org/~cbbrowne/unix.html In case you weren't aware, ad homineum is not latin for the user of this technique is a fine debater. -- Thomas F. Burdick ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] APR 1.0 released
Centuries ago, Nostradamus foresaw when [EMAIL PROTECTED] (Marc G. Fournier) would write: On Sat, 4 Sep 2004, Gaetano Mendola wrote: Hi all, now that Apache Portable Runtime was release why don't use it on Postgres? Short question: why? what does it give us, other then potential reliance on another project to build ... ? It would allow reopening all the threads about why PostgreSQL doesn't use threading... That being said, there are places where there would be merit to using threading in PostgreSQL, though NOT where the usual futile discussions ask for it. Notably, on an SMP system, it would be a neat idea for complex queries involving joins to split themselves so that different parts run in separate threads. The other Way, Way Cool part would be for queries that are scanning big tables to split the scans into unions of partial scans, so that on an 8 CPU box you'd take the Big 4GB Table and have 8 threads simultaneously scanning different parts of it. (And making ARC all the more important :-).) But that would, however it happened, involve BIG, SCARY changes... ... And since APR isn't BSD licensed, that would probably cause a problem. -- (format nil [EMAIL PROTECTED] cbbrowne acm.org) http://www3.sympatico.ca/cbbrowne/wp.html Of course, unless one has a theory, one cannot expect much help from a computer unless _it_ has a theory)... -- Marvin Minsky ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
[HACKERS] Error starting PostgreSQL on Win XP: failed to get token information: 122
Hi Thanks for PostgreSQL Beta 8.0! I try to use the native Win32 build (http://pgfoundry.org/projects/pginstaller) (Beta 1) but i get an error during DB startup. failed to get token information: 122 Maybe this is related to http://groups.google.com/groups?hl=enlr=ie=UTF-8selm=cftihc%247uk%241%40sea.gmane.org My computer is part of 8 security groups My user is part of 35 security groups (used gpresult.exe to figure out) I do not run PostgreSQL as service (I'll start it by CLI) Any Ideas? Regards Bruno Grossniklaus ---(end of broadcast)--- TIP 8: explain analyze is your friend
[HACKERS] beta2 and blob's
Hi with beta2 i get
leak:relation pg_largeobject_loid_pn_index has refcnt 1 instead of 0
while running my script
that's an example throwing this message
UPDATE reports SET r_blob=lo_import('../reports.r_id.'|| CAST(r_id AS
VARCHAR) || '.blob') WHERE r_blob IS NOT NULL
PS : everything seem to be done in the right way. My data is ok.
Daniel
---(end of broadcast)---
TIP 8: explain analyze is your friend
[HACKERS] beta 2 crash with unique constraints
Hi List, I have another error now here:
notice that only one backend is dying, all others are up and working.
Error - Message :
duplicate key violates unique constraint ferber_rust_params_pkey
FATAL: block 0 of 1663/19335/476756 is still referenced (local 2)
server closed the connection unexpectedly
This probably means the server terminated abnormally
before or while
here is a sample script causing this server-crash (simple cut and paste)
BEGIN;
CREATE SEQUENCE dbridseq;
CREATE TABLE ferber_rust_params
(fbrp_id SERIAL PRIMARY KEY,
fbrp_pos INTEGER,
fbrp_ferber VARCHAR(20),
fbrp_descr VARCHAR(80) NOT NULL,
fbrp_nameVARCHAR(10) NOT NULL,
fbrp_default FLOAT4,
fbrp_formula VARCHAR(100),
dbridVARCHAR UNIQUE DEFAULT nextval('dbridseq')
);
INSERT INTO ferber_rust_params (fbrp_id, fbrp_pos, fbrp_ferber,
fbrp_descr, fbrp_name, fbrp_default, fbrp_formula, dbrid) VALUES (6, 4,
'BSRUND', 'Vorschub aus Tabelle', 'vorschub', 360,
'vorschub-(vorschub/100*40)', '337941');
SELECT * INTO TEMP TABLE ferber_rus_205102 FROM ferber_rust_params WHERE
fbrp_ferber='BSRUND';
UPDATE ferber_rus_205102 SET fbrp_name='BSRUND1';
ALTER TABLE ferber_rus_205102 DROP COLUMN dbrid;
INSERT INTO ferber_rust_params SELECT * FROM ferber_rus_205102;
ROLLBACK;
PS : Running Windows XP Home.
Daniel
BEGIN;
CREATE SEQUENCE dbridseq;
CREATE TABLE ferber_rust_params
(fbrp_id SERIAL PRIMARY KEY,
fbrp_pos INTEGER,
fbrp_ferber VARCHAR(20), --REFERENCES ferber ON UPDATE CASCADE ON DELETE
CASCADE,
fbrp_descr VARCHAR(80) NOT NULL,
fbrp_nameVARCHAR(10) NOT NULL,
fbrp_default FLOAT4,
fbrp_formula VARCHAR(100),
dbridVARCHAR UNIQUE DEFAULT nextval('dbridseq')
);
INSERT INTO ferber_rust_params (fbrp_id, fbrp_pos, fbrp_ferber, fbrp_descr, fbrp_name,
fbrp_default, fbrp_formula, dbrid) VALUES (6, 4, 'BSRUND', 'Vorschub aus Tabelle',
'vorschub', 360, 'vorschub-(vorschub/100*40)', '337941');
SELECT * INTO TEMP TABLE ferber_rus_205102 FROM ferber_rust_params WHERE
fbrp_ferber='BSRUND';
UPDATE ferber_rus_205102 SET fbrp_name='BSRUND1';
ALTER TABLE ferber_rus_205102 DROP COLUMN dbrid;
INSERT INTO ferber_rust_params SELECT * FROM ferber_rus_205102;
ROLLBACK;
---(end of broadcast)---
TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] Unknown Exception (chr@active.ch)
Achtung neue Mail-Adresse ! Neu: vorname.familienname bei gleichem Provider oder rufen Sie uns bitte an (01/977 13 77) und wir werde die neue Adresse mitteilen. Leider erhalten wir pro Tag mehr als 100 Mails welche wir nicht wollen. Wir haben uns daher entschieden, eine neue Adresse zu waehlen. Ihr Mail wird bei uns auf dem Mailserver automatisch geloescht ! ---(end of broadcast)--- TIP 8: explain analyze is your friend
