Re: [HACKERS] HEADS UP: Win32/OS2/BeOS native ports
I think its already been determined that the cygwin option is too low performing. However, the apache stuff could be quite useful - but if that effort were to be undertaken, it would make more sense to move all versions of the code the the apache runtime, for all platforms. Are there any other runtime libraries out there that are cross platform, open/free and high performance? I know the mozilla XPCOM libraries work quite nicely, but are geared more towards multithreaded apps - and the COM-alike infrastructure is something we wouldn't need. ~Jon - Original Message - From: Bruce Momjian [EMAIL PROTECTED] To: mlw [EMAIL PROTECTED] Cc: Tom Lane [EMAIL PROTECTED]; Marc G. Fournier [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Sunday, June 02, 2002 8:49 PM Subject: Re: [HACKERS] HEADS UP: Win32/OS2/BeOS native ports mlw wrote: Like I told Marc, I don't care. You spec out what you want and I'll write it for Windows. That being said, a SysV IPC interface for native Windows would be kind of cool to have. I am wondering why we don't just use the Cygwin shm/sem code in our project, or maybe the Apache stuff; why bother reinventing the wheel. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup.| Drexel Hill, Pennsylvania 19026 ---(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 ---(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] HEADS UP: Win32/OS2/BeOS native ports
Yes, I am having trouble figuring out if I have seen the whole thread yet. --- Marc G. Fournier wrote: You might want to go to the archives and catch up on the whole thread and its digressions :) On Sun, 2 Jun 2002, Bruce Momjian wrote: mlw wrote: Like I told Marc, I don't care. You spec out what you want and I'll write it for Windows. That being said, a SysV IPC interface for native Windows would be kind of cool to have. I am wondering why we don't just use the Cygwin shm/sem code in our project, or maybe the Apache stuff; why bother reinventing the wheel. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup.| Drexel Hill, Pennsylvania 19026 -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup.| Drexel Hill, Pennsylvania 19026 ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] non-standard escapes in string literals
Andrew Pimlott wrote: On Wed, May 08, 2002 at 06:47:46PM +0200, Zeugswetter Andreas SB SD wrote: When we are talking about the places where you need double escaping (once for parser, once for input function) to make it work, I would also say that that is very cumbersome (not broken, since it is thus documented) :-) I would also default to strict ANSI, but not depricate the escaping when set. All imho of course. As the original reporter of this issue, I am gratified to hear it acknowledged by the developers. Thanks! (I also apologize if I exaggerated the pain caused, as apparently not many other people have been bitten by this specific problem. Well, it was painful for me. ;-) ) I must say, though, that I remain bothered by the not broken attitude. There is an obvious standard for PostgreSQL to follow, yet it is non-compliant in utterly trivial ways, which provide marginal or no benefits. Granted, changing long-standing defaults may not be acceptible; but there is a big difference between, it is broken but we just can't change it for compatibility reasons, and, it is not broken. It is my experience that most other free software projects take standards compliance more seriously than PostgreSQL, and my strong opinion that both the project and its users (not to mention the whole SQL database industry, eventually) would benefit from better support for the SQL standard. Ok, I've said my peace. Yes, these are good points. Our big problem is that we use backslash for two things, one for escaping single quotes and for escaping standard C characters, like \n. While we can use the standard-supported '' to insert single quotes, what should we do with \n? The problem is switching to standard ANSI solution reduces our functionality. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup.| Drexel Hill, Pennsylvania 19026 ---(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] non-standard escapes in string literals
On Mon, June 03 Bruce wrote: On Wed, May 08, 2002 at 06:47:46PM +0200, Zeugswetter SB SD Andreas wrote: When we are talking about the places where you need double escaping (once for parser, once for input function) to make it work, I would also say that that is very cumbersome (not broken, since it is thus documented) :-) I would also default to strict ANSI, but not depricate the escaping when set. All imho of course. Yes, these are good points. Our big problem is that we use backslash for two things, one for escaping single quotes and for escaping standard C characters, like \n. While we can use the standard-supported '' to insert single quotes, what should we do with \n? The problem is switching to standard ANSI solution reduces our functionality. The problem imho is, that this (no doubt in many cases valuable) feature reduces the functionality from the ANSI SQL perspective. Consider a field that is supposed to store Windows filenames, nam_file='C:\node1\resend\b.dat' :-) Thus I think a GUC to turn off all escaping except '' would be valuable. Andreas ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] HEADS UP: Win32/OS2/BeOS native ports
You might want to go to the archives and catch up on the whole thread and its digressions :) On Sun, 2 Jun 2002, Bruce Momjian wrote: mlw wrote: Like I told Marc, I don't care. You spec out what you want and I'll write it for Windows. That being said, a SysV IPC interface for native Windows would be kind of cool to have. I am wondering why we don't just use the Cygwin shm/sem code in our project, or maybe the Apache stuff; why bother reinventing the wheel. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup.| Drexel Hill, Pennsylvania 19026 ---(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] HEADS UP: Win32/OS2/BeOS native ports
Bruce Momjian wrote: mlw wrote: Like I told Marc, I don't care. You spec out what you want and I'll write it for Windows. That being said, a SysV IPC interface for native Windows would be kind of cool to have. I am wondering why we don't just use the Cygwin shm/sem code in our project, or maybe the Apache stuff; why bother reinventing the wheel. I have not been participating on the list, I don't know why I'm still receiving mail. but! in the course of testing some code, I managed to gain some experience with cygwin. I have seen fork() problems with a large number of processes. For PostgreSQL to be as good on Windows as it is on UNIX, it has to be a native program without cygwin. The shared memory and semaphore management should be done with the postmaster process. The apache stuff is OK, it is just as good as anything else. You may be able to use critical sections in shared memory to implement a fast semaphore, but that would take a bit experimentation. I think what Tom had in mind is to take out the SysV and various OS specific APIs and replace them with a more generic one, behind which, you guys can tune the implementation. ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] HEADS UP: Win32/OS2/BeOS native ports
Bruce, On Sun, Jun 02, 2002 at 08:49:21PM -0400, Bruce Momjian wrote: mlw wrote: Like I told Marc, I don't care. You spec out what you want and I'll write it for Windows. That being said, a SysV IPC interface for native Windows would be kind of cool to have. I am wondering why we don't just use the Cygwin shm/sem code in our project, or maybe the Apache stuff; why bother reinventing the wheel. Are you referring to cygipc above? If so, they even one of the original cygipc authors would discourage this: http://sources.redhat.com/ml/cygwin-apps/2001-09/msg00017.html Specifically, Ludovic Lange states the following: I really think the solution would be to start again from scratch another implementation, as was suggested. The way we did it was quick and dirty, the goals weren't to have production systems running on it but only to run prototypes. So the internal design (if there is any) may not be adequate for the cygwin project. However, Rob Collins has contributed a MinGW daemon to Cygwin to support switching users, System V IPC, etc. So, this code base may be a more suitable starting point to satisfy PostgreSQL's native Win32 System V IPC needs. Jason ---(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] HEADS UP: Win32/OS2/BeOS native ports
On Sun, Jun 02, 2002 at 09:33:57PM -0400, mlw wrote: Bruce Momjian wrote: mlw wrote: Like I told Marc, I don't care. You spec out what you want and I'll write it for Windows. That being said, a SysV IPC interface for native Windows would be kind of cool to have. I am wondering why we don't just use the Cygwin shm/sem code in our project, or maybe the Apache stuff; why bother reinventing the wheel. but! in the course of testing some code, I managed to gain some experience with cygwin. I have seen fork() problems with a large number of processes. Since Cygwin's fork() is implemented with WaitForMultipleObjects(), it has a limitation of only 63 children per parent. Also, there can be DLL base address conflicts (causing Cygwin fork() to fail) that are avoidable by rebasing the appropriate DLLs. AFAICT, Cygwin PostgreSQL is currently *not* affected by this issue where as other Cygwin applications such as Python and Apache are. Jason ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] HEADS UP: Win32/OS2/BeOS native ports
Jason Tishler wrote: On Sun, Jun 02, 2002 at 09:33:57PM -0400, mlw wrote: Bruce Momjian wrote: mlw wrote: Like I told Marc, I don't care. You spec out what you want and I'll write it for Windows. That being said, a SysV IPC interface for native Windows would be kind of cool to have. I am wondering why we don't just use the Cygwin shm/sem code in our project, or maybe the Apache stuff; why bother reinventing the wheel. but! in the course of testing some code, I managed to gain some experience with cygwin. I have seen fork() problems with a large number of processes. Since Cygwin's fork() is implemented with WaitForMultipleObjects(), it has a limitation of only 63 children per parent. Also, there can be DLL base address conflicts (causing Cygwin fork() to fail) that are avoidable by rebasing the appropriate DLLs. AFAICT, Cygwin PostgreSQL is currently *not* affected by this issue where as other Cygwin applications such as Python and Apache are. Whatever technical problems there are, we can debate on and on if it's worth working around them in PostgreSQL or fixing them in CygWIN or whatever. The main problem will remain. That using PostgreSQL under CygWIN requires some UNIX know how. So a pure Windows user/shop needs UNIX knowledge to run our Windows port of PostgreSQL? Interesting definition of port. Jan -- #==# # It's easier to get forgiveness for being wrong than for being right. # # Let's break this rule - forgive me. # #== [EMAIL PROTECTED] # ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] HEADS UP: Win32/OS2/BeOS native ports - the 'BEST OPEN SOURCE database backend'
Hi, You may want to have a look at: http://www.garret.ru/~knizhnik/ You find there code for a 'Fast synchronized access to shared memory for Windows and for i86 Unix-es. kind regards, Robert Bruce, On Sun, Jun 02, 2002 at 08:49:21PM -0400, Bruce Momjian wrote: mlw wrote: Like I told Marc, I don't care. You spec out what you want and I'll write it for Windows. That being said, a SysV IPC interface for native Windows would be kind of cool to have. I am wondering why we don't just use the Cygwin shm/sem code in our project, or maybe the Apache stuff; why bother reinventing the wheel. Are you referring to cygipc above? If so, they even one of the original cygipc authors would discourage this: http://sources.redhat.com/ml/cygwin-apps/2001-09/msg00017.html Specifically, Ludovic Lange states the following: I really think the solution would be to start again from scratch another implementation, as was suggested. The way we did it was quick and dirty, the goals weren't to have production systems running on it but only to run prototypes. So the internal design (if there is any) may not be adequate for the cygwin project. However, Rob Collins has contributed a MinGW daemon to Cygwin to support switching users, System V IPC, etc. So, this code base may be a more suitable starting point to satisfy PostgreSQL's native Win32 System V IPC needs. Jason ---(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 4: Don't 'kill -9' the postmaster
[HACKERS] GOODS - a sensational public domain database backend that deserves a SQL frontend
Hi, Some of you might already know GOODS, programmed almost entirely by Konstantin Knizhnik - if not you should really have a look at it right now (be warned: consuming this extraordinary work might change your levels about the required quality of a 'good programmer' forever. At least this happend to me... ;): http://www.garret.ru/~knizhnik/goods.html Some core features of this backend (as they come to my mind): - full ACID transaction support - distributed stoarge management (-distributed transactions) - multible reader/single writer (is this called MVCC within PostgreSQL?) - dual client side object cache - online backup (snapshot backup AND permanent backup) - nested transactions on object level - transaction isolation levels on object level - object level shared and exclusive locks - excellent C++ programming interface - WAL - garbage collection for no longer reference database objects - fully thread safe client interface - JAVA client API - very high performance as a result of a lot of fine tuning - asyncrous event notification on object instance modification - extremly high code quality - a one person effort, hence a very clean design - the most relevant platforms are supported out of the box - complete build is done in less than a minute on my machine - it's documented ... The licensing of this coding wonder: PUBLIC DOMAIN I'm using GOODS quiet a while now in the context of my development activities for a native XML database and have very promissing experiences concerning performance and stability of GOODS. E.g.: The performance seems to be better than sleepycat's berkeley db library - especially with mutliple simultanous transactions... Maybe the only restriction to use this backend in postgres from now on: it's completely C++ ... I'm wondering why there is no SQL frontend yet for this execellent backend... You may want to look also at a comparision chart of some other backends than GOODS (some of them from the same author!!! I'm wondering how he was able to code all this...): http://www.garret.ru/~knizhnik/compare.html kind regards, Robert ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] HEADS UP: Win32/OS2/BeOS native ports
On Mon, Jun 03, 2002 at 09:36:51AM -0400, mlw wrote: Jason Tishler wrote: On Sun, Jun 02, 2002 at 09:33:57PM -0400, mlw wrote: Bruce Momjian wrote: mlw wrote: Like I told Marc, I don't care. You spec out what you want and I'll write it for Windows. That being said, a SysV IPC interface for native Windows would be kind of cool to have. I am wondering why we don't just use the Cygwin shm/sem code in our project, or maybe the Apache stuff; why bother reinventing the wheel. but! in the course of testing some code, I managed to gain some experience with cygwin. I have seen fork() problems with a large number of processes. Since Cygwin's fork() is implemented with WaitForMultipleObjects(), it has a limitation of only 63 children per parent. Also, there can be DLL base address conflicts (causing Cygwin fork() to fail) that are avoidable by rebasing the appropriate DLLs. AFAICT, Cygwin PostgreSQL is currently *not* affected by this issue where as other Cygwin applications such as Python and Apache are. Why would not PostgreSQL be affected by this? Sorry, if I was unclear -- I should have used two paragraphs above and maybe a few more words... :,) Cygwin PostgreSQL *is* affected by the Cygwin 63 children per parent fork limitation. PostgreSQL *can* be affected by the Cygwin DLL base address conflict fork issue, but in my experience (both personal and by monitoring the Cygwin and pgsql-cygwin lists), no one has been affected yet. The DLL base address conflict is a probability thing. The more DLLs loaded the greater the chance of a conflict (and fork() failing). Since, Cygwin PostgreSQL loads only a few DLLs, this has not become an issue (yet). Jason ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] non-standard escapes in string literals
At 01:20 PM 6/3/02 +0200, Zeugswetter Andreas SB SD wrote: for two things, one for escaping single quotes and for escaping standard C characters, like \n. While we can use the standard-supported '' to insert single quotes, what should we do with \n? The problem is switching to standard ANSI solution reduces our functionality. The problem imho is, that this (no doubt in many cases valuable) feature reduces the functionality from the ANSI SQL perspective. Consider a field that is supposed to store Windows filenames, nam_file='C:\node1\resend\b.dat' :-) Thus I think a GUC to turn off all escaping except '' would be valuable. With current behaviour 'C:\node1\resend\b.dat' can be quoted as 'C:\\node1\\resend\\b.dat' But for the ANSI standard how does one stuff \r\n\t and other control characters into the database? If there's no way other than actually sending the control characters then that is a bad idea especially from a security viewpoint. Cheerio, Link. ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] GOODS - a sensational public domain database backend
Kostya is a good qualified programmer. I know him and he is always open for challenges. Some time ago, me and Teodor ask him about GiST support in his another database (Gigabase). It was sort of challenge ( we wanted to port our contrib/tsearch module ) and he did that (using libgist). We work with gigabase database embedded into our application under Windows (we had a lot of troubles with perforance of postgresql under Cygwin:-) and quite happy. On Mon, 3 Jun 2002, Robert Schrem wrote: Hi, Some of you might already know GOODS, programmed almost entirely by Konstantin Knizhnik - if not you should really have a look at it right now (be warned: consuming this extraordinary work might change your levels about the required quality of a 'good programmer' forever. At least this happend to me... ;): http://www.garret.ru/~knizhnik/goods.html Some core features of this backend (as they come to my mind): - full ACID transaction support - distributed stoarge management (-distributed transactions) - multible reader/single writer (is this called MVCC within PostgreSQL?) - dual client side object cache - online backup (snapshot backup AND permanent backup) - nested transactions on object level - transaction isolation levels on object level - object level shared and exclusive locks - excellent C++ programming interface - WAL - garbage collection for no longer reference database objects - fully thread safe client interface - JAVA client API - very high performance as a result of a lot of fine tuning - asyncrous event notification on object instance modification - extremly high code quality - a one person effort, hence a very clean design - the most relevant platforms are supported out of the box - complete build is done in less than a minute on my machine - it's documented ... The licensing of this coding wonder: PUBLIC DOMAIN I'm using GOODS quiet a while now in the context of my development activities for a native XML database and have very promissing experiences concerning performance and stability of GOODS. E.g.: The performance seems to be better than sleepycat's berkeley db library - especially with mutliple simultanous transactions... Maybe the only restriction to use this backend in postgres from now on: it's completely C++ ... I'm wondering why there is no SQL frontend yet for this execellent backend... You may want to look also at a comparision chart of some other backends than GOODS (some of them from the same author!!! I'm wondering how he was able to code all this...): http://www.garret.ru/~knizhnik/compare.html kind regards, Robert ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster Regards, Oleg _ Oleg Bartunov, sci.researcher, hostmaster of AstroNet, Sternberg Astronomical Institute, Moscow University (Russia) Internet: [EMAIL PROTECTED], http://www.sai.msu.su/~megera/ phone: +007(095)939-16-83, +007(095)939-23-83 ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
[HACKERS] patch for contrib/intarray (7.2 and 7.3)
Please apply attached patch to contrib/intarray (7.2, 7.3). Fixed bug with '=' operator for gist__int_ops and define '=' operator for gist__intbig_ops opclass. Now '=' operator is consistent with standard 'array' type. br Tnanks Achilleus Mantzios for bug report and suggestion. Regards, Oleg _ Oleg Bartunov, sci.researcher, hostmaster of AstroNet, Sternberg Astronomical Institute, Moscow University (Russia) Internet: [EMAIL PROTECTED], http://www.sai.msu.su/~megera/ phone: +007(095)939-16-83, +007(095)939-23-83 patch_intarray.gz Description: Binary data ---(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] pgsql_data/base mapping
Laurette Cisneros wrote: Are the numbers of the directories in the base diretory and the numbers of the directories under that, etc. traceable to a reference somewhere in the postgresql server using that data directory (such as the pg_database table or such)? If so, is there somewhere this is documented? You can use /contrib/oid2name to get the database names and table names from the oid file numbers. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup.| Drexel Hill, Pennsylvania 19026 ---(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] code contribution
Sorry, I am just getting to this. I have the patch in my email box too. Can you explain what buffer of line is? I want to know if it is of general usefulness. --- Alex Shevlakov wrote: New 'path' functions (test results can be found at http://motivation.ru/grass/buff_q_example.html): There are not many (as my task was only limited to extending GRASS vector capabilities to buffering): /*check if a point is within buffer of line*/ Datum path_buffer_contain_pt(PG_FUNCTION_ARGS); /*removes multiple repeated points from path*/ Datum path_without_doubles (PG_FUNCTION_ARGS); static PATH * path_no_dbles(PATH *path); /*returns closed path which is buffer to another path*/ Datum return_path_buffer(PG_FUNCTION_ARGS); /*used to insert points along circle segment between two ends of non-intersecting buffer segments, smoothing the buffer*/ static Point * point_rotate (Point *lpoint, Point *ax_point, float ang, int k, int n, int napr); /*writes path to arcinfo UNGENERATE format which is particularly useful for viewing buffer in GRASS*/ Datum write_path_to_file(PG_FUNCTION_ARGS); int write_path_to_file_internal(PATH *path, char *str ); /*generalize path,i.e., leave each third, or fourth, etc., point*/ Datum reduce_path_points(PG_FUNCTION_ARGS); static PATH *path_reduce(PATH * path, int n_reduce); On Tue, May 07, 2002 at 07:01:05AM -0700, Thomas Lockhart wrote: I'd like to contribute new code for Postgres geometry type 'path' operations (including line buffer). Where should I send this? Send to [EMAIL PROTECTED] It may be helpful to (i.e. please do) post a summary of what you are intending to send to this mailing list so folks have an idea of what is coming... Regards. - Tom ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED] -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup.| Drexel Hill, Pennsylvania 19026 ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] HEADS UP: Win32/OS2/BeOS native ports
That's what Apache does. Note, on most platforms MAP_ANON is equivalent to mmmap-ing /dev/zero. Solaris for example does not provide MAP_ANON but using fd=open(/dev/zero) mmap(fd, ...) close(fd) works just fine. - Original Message - From: Bruce Momjian [EMAIL PROTECTED] To: Igor Kovalenko [EMAIL PROTECTED] Cc: Tom Lane [EMAIL PROTECTED]; mlw [EMAIL PROTECTED]; Marc G. Fournier [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Sunday, June 02, 2002 7:47 PM Subject: Re: [HACKERS] HEADS UP: Win32/OS2/BeOS native ports Igor Kovalenko wrote: It does not have to be anonymous. POSIX also defines shm_open(same arguments as open) API which will create named object in whatever location corresponds to shared memory storage on that platform (object is then grown to needed size by ftruncate() and the fd is then passed to mmap). The object will exist in name space and can be detected by subsequent calls to shm_open() with same name. It is not really different from doing open(), but more portable (mmap() on regular files may not be supported). Actually, I think the best shared memory implemention would be MAP_ANON | MAP_SHARED mmap(), which could be called from the postmaster and passed to child processes. While all our platforms have mmap(), many don't have MAP_ANON, but those that do could use it. You need MAP_ANON to prevent the shared memory from being written to a disk file. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup.| Drexel Hill, Pennsylvania 19026 ---(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] Search from newer tuples first, vs older tuples first?
Bruce Momjian [EMAIL PROTECTED] writes: It is not that hard to implement, just messy. When the index returns a heap row and the heap row is viewed for visibility, if _no_one_ can see the row, the index can be marked as expired. It could be a single bit in the index tuple, and doesn't need to be flushed to disk, though the index page has to be marked as dirty. However, we are going to need to flush a pre-change image to WAL so it may as well be handled as a normal index page change. This did actually get done while you were on vacation. It does *not* need a WAL entry, on the same principle that setting XMIN_COMMITTED, XMAX_ABORTED, etc hint bits do not need WAL entries --- namely the bits can always get set again if they are lost in a crash. regards, tom lane ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Search from newer tuples first, vs older tuples first?
Tom Lane wrote: Bruce Momjian [EMAIL PROTECTED] writes: It is not that hard to implement, just messy. When the index returns a heap row and the heap row is viewed for visibility, if _no_one_ can see the row, the index can be marked as expired. It could be a single bit in the index tuple, and doesn't need to be flushed to disk, though the index page has to be marked as dirty. However, we are going to need to flush a pre-change image to WAL so it may as well be handled as a normal index page change. This did actually get done while you were on vacation. It does *not* need a WAL entry, on the same principle that setting XMIN_COMMITTED, XMAX_ABORTED, etc hint bits do not need WAL entries --- namely the bits can always get set again if they are lost in a crash. Oh, thanks. That is great news. I am having trouble determining when a thread ends so please be patient with me. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup.| Drexel Hill, Pennsylvania 19026 ---(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] Search from newer tuples first, vs older tuples first?
Tom Lane wrote: Bruce Momjian [EMAIL PROTECTED] writes: It is not that hard to implement, just messy. When the index returns a heap row and the heap row is viewed for visibility, if _no_one_ can see the row, the index can be marked as expired. It could be a single bit in the index tuple, and doesn't need to be flushed to disk, though the index page has to be marked as dirty. However, we are going to need to flush a pre-change image to WAL so it may as well be handled as a normal index page change. This did actually get done while you were on vacation. It does *not* need a WAL entry, on the same principle that setting XMIN_COMMITTED, XMAX_ABORTED, etc hint bits do not need WAL entries --- namely the bits can always get set again if they are lost in a crash. TODO item marked as done: * -Add deleted bit to index tuples to reduce heap access -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup.| Drexel Hill, Pennsylvania 19026 ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Cygwin / Debian dpkg / PostgreSQL / KDE2 and 3
Jean-Michel POURE wrote: - creating a PostgreSQL + Cygwin modern GUI installer. All required .DEB packages would be downloaded and installed from Debian mirrors, with little user intervention. PostgreSQL would be installed as a service. - a cross-platform GUI environment for (future) pgAdmin. Please note I am not dealing with pgAdmin future. Dave Page thinks Mono is the solution. I don't agree and think we should use Cygwin-KDE or native Windows libraries. This may be a stupid question, but could the new Mozilla be used as a cross-platform GUI? Seems like a natural because it is supposed to be more of a platform with a browser built on top. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup.| Drexel Hill, Pennsylvania 19026 ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
