Re: [HACKERS] msg translation into sk_SK, Docs: SGML - XML
On Thu, Jan 29, 2004 at 07:02:12PM +0100, Peter Eisentraut wrote: Peter E. works on XML docbook version of docs. I don't know if he wants to move directly to XML or uses on the fly conversion to XML by osx (sgml2xml). This conversion you try use by make testxml stuff in the doc/src/sgml/Makefile. I tested it and it works -- but for example conversion from XML to PDF by fop failed, but it's might be fop problem. The general consensus is that FOP is simply not there yet. Do you how idea how convert XML to fo or directly to pdf? Peter, what's your planns? Well, when people feel good about it, we can switch the stored format to XML. I'm not in a hurry, though, because what is there right now is I feel good about it. The important thing is support in Makefiles XML conversion to other formats like HTML, PDF and man. It's strange if after release almost nobody has idea how create PDF docs. almost equivalent. I've also tried out the po2xml thingy and it seems to work, but translating about 1 strings seems to be a daunting task. Be optimistic! ;-) Karel -- Karel Zak [EMAIL PROTECTED] http://home.zf.jcu.cz/~zakkr/ Information from NOD32 This message was checked by NOD32 Antivirus System for Linux Mail Server. http://www.nod32.com ---(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] Getting the results columns before execution
Jan Wieck wrote: Tom Lane wrote: Bruce Momjian [EMAIL PROTECTED] writes: Tom Lane wrote: Are those exposed through the libpq interface? No, because libpq doesn't really have any concept of prepared statements. It would probably make sense to add some more API to libpq to allow creation and interrogation of prepared statements, but no one's got around to that yet. Uh, if libpq doesn't know about it, how is that information accessed? That's exactly the problem... Currently the only way to do that would be to have a user defined function that calls SPI_prepare() with the query string and returns the desired information to the client. It was my understanding that the new protocol passes this information to the cilent, 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 7: don't forget to increase your free space map settings
Re: [HACKERS] Getting the results columns before execution
Jan Wieck wrote: Tom Lane wrote: Bruce Momjian [EMAIL PROTECTED] writes: Tom Lane wrote: Are those exposed through the libpq interface? No, because libpq doesn't really have any concept of prepared statements. It would probably make sense to add some more API to libpq to allow creation and interrogation of prepared statements, but no one's got around to that yet. Uh, if libpq doesn't know about it, how is that information accessed? That's exactly the problem... Currently the only way to do that would be to have a user defined function that calls SPI_prepare() with the query string and returns the desired information to the client. Oh, I understand now. Added to TODO: * Allow libpq to return information about prepared queries -- 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] Question about indexes
Greg Stark wrote: Tom Lane [EMAIL PROTECTED] writes: In any case, this discussion is predicated on the assumption that the operations involving the bitmap are a significant fraction of the total time, which I think is quite uncertain. Until we build it and profile it, we won't know that. The other thought I had was that it would be difficult to tell when to follow this path. Since the main case where it wins is when the individual indexes aren't very selective but the combination is very selective, and we don't have inter-column correlation statistics ... I like the idea of building in-memory bitmapped indexes. In your example, if you are restricting on A and B, and have no A,B index but an A index and B index, why wouldn't you always create an in-memory bitmapped index from indexes A and B, unless index A hits only a few rows. In fact, from the optimizer statistics, you can guess on how many bits you will hit from index A and index B, so we only have to decide if it is better to take the more restrictive index and do heap lookups for those, or scan the second index and then hit the heap. The only thing A,B combined statistics would tell you is how many heap matches you will find. The time to scan A and B indexes and create the bitmap is already guessable from the single column statistics. Also, what does an in-memory bitmapped index look like? Is it: value: bitmap... value: bitmap... with the values organized in a btree fashion? -- 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] Stupid question on Read Committed Isolation Level
On Thu, Jan 29, 2004 at 03:27:06PM -0400, Marc G. Fournier wrote: I would say that two such transactions concurrently heavily implies such, no? :) Like I said, the text tries to explain it--but it remains murky! ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] 7.5 change documentation
Richard Huxton wrote: On Wednesday 28 January 2004 00:38, Simon Riggs wrote: POSTGRESQL: Summary of Changes since last release (7.4.1) All corrections and changes welcome...if this is well received, then I will monitor pgsql-commiters to keep track of things. Speaking as JustAUser (TM) I find this very useful. I always have trouble keeping track on what may/probably/will appear in upcoming versions when people ask on the lists. Yes, very nice. We could link to it from the developers page. -- 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] Question about indexes
Bruce Momjian [EMAIL PROTECTED] writes: Also, what does an in-memory bitmapped index look like? One idea that might work: a binary search tree in which each node represents a single page of the table, and contains a bit array with one bit for each possible item number on the page. You could not need more than BLCKSZ/(sizeof(HeapTupleHeaderData)+sizeof(ItemIdData)) bits in a node, or about 36 bytes at default BLCKSZ --- for most tables you could probably prove it would be a great deal less. You only allocate nodes for pages that have at least one interesting row. I think this would represent a reasonable compromise between size and insertion speed. It would only get large if the indexscan output demanded visiting many different pages --- but at some point you could abandon index usage and do a sequential scan, so I think that property is okay. A variant is to make the per-page bit arrays be entries in a hash table with page number as hash key. This would reduce insertion to a nearly constant-time operation, but the drawback is that you'd need an explicit sort at the end to put the per-page entries into page number order before you scan 'em. You might come out ahead anyway, not sure. Or we could try a true linear bitmap (indexed by page number times max-items-per-page plus item number) that's compressed in some fashion, probably just by eliminating large runs of zeroes. The difficulty here is that inserting a new one-bit could be pretty expensive, and we need it to be cheap. Perhaps someone can come up with other better ideas ... regards, tom lane ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] Question about indexes
On Fri, Jan 30, 2004 at 09:48:19AM -0500, Tom Lane wrote: A variant is to make the per-page bit arrays be entries in a hash table with page number as hash key. This would reduce insertion to a nearly constant-time operation, but the drawback is that you'd need an explicit sort at the end to put the per-page entries into page number order before you scan 'em. You might come out ahead anyway, not sure. Is there a reason sort the pages before scanning them? The result won't come out sorted one way or the other. -- Alvaro Herrera (alvherre[a]dcc.uchile.cl) Para tener más hay que desear menos ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Question about indexes
Alvaro Herrera wrote: On Fri, Jan 30, 2004 at 09:48:19AM -0500, Tom Lane wrote: A variant is to make the per-page bit arrays be entries in a hash table with page number as hash key. This would reduce insertion to a nearly constant-time operation, but the drawback is that you'd need an explicit sort at the end to put the per-page entries into page number order before you scan 'em. You might come out ahead anyway, not sure. Is there a reason sort the pages before scanning them? The result won't come out sorted one way or the other. I think the goal would be to hit the heap in sequential order as much as possible. When we are doing reading right from the index, we haven't collected all the heap values in one place, but since we have them in memory, we might as well sort them, though I don't think that is a requirement, just a performance enhancement, or at least that is my guess. -- 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
Re: [HACKERS] Question about indexes
Bruce Momjian [EMAIL PROTECTED] writes: Alvaro Herrera wrote: Is there a reason sort the pages before scanning them? The result won't come out sorted one way or the other. I think the goal would be to hit the heap in sequential order as much as possible. Exactly. Also, it'll be harder to AND or OR two bitmaps together if you don't presort their pages. (I think the hash representation could do OR without presort, but not AND.) regards, tom lane ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
[HACKERS] Fix for win32 sleep
I have applied the following patch for the following reasons:
Remove sleep() and use single PG_SLEEP call for Win32 signal handling
and consistency.
Change PG_USLEEP to use SleepEx() for signal interuptability.
--
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/backend/storage/buffer/bufmgr.c
===
RCS file: /cvsroot/pgsql-server/src/backend/storage/buffer/bufmgr.c,v
retrieving revision 1.153
diff -c -c -r1.153 bufmgr.c
*** src/backend/storage/buffer/bufmgr.c 24 Jan 2004 20:00:45 - 1.153
--- src/backend/storage/buffer/bufmgr.c 30 Jan 2004 15:55:05 -
***
*** 1058,1067
* Nap for the configured time or sleep for 10 seconds if
* there was nothing to do at all.
*/
! if (n 0)
! PG_USLEEP(BgWriterDelay * 1000);
! else
! sleep(10);
}
}
--- 1058,1064
* Nap for the configured time or sleep for 10 seconds if
* there was nothing to do at all.
*/
! PG_USLEEP((n 0) ? BgWriterDelay * 1000 : 1000);
}
}
Index: src/include/miscadmin.h
===
RCS file: /cvsroot/pgsql-server/src/include/miscadmin.h,v
retrieving revision 1.148
diff -c -c -r1.148 miscadmin.h
*** src/include/miscadmin.h 26 Jan 2004 22:59:53 - 1.148
--- src/include/miscadmin.h 30 Jan 2004 15:55:06 -
***
*** 109,115
#else
#define PG_USLEEP(_usec) \
do { \
! Sleep((_usec) 500 ? 1 : ((_usec)+500)/ 1000); \
} while(0)
#endif
--- 109,115
#else
#define PG_USLEEP(_usec) \
do { \
! SleepEx(((_usec) 500 ? 1 : ((_usec) + 500) / 1000), TRUE); \
} while(0)
#endif
---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Question about indexes
On Jan 30, 2004, at 6:31 AM, Bruce Momjian wrote: I like the idea of building in-memory bitmapped indexes. Me too (FWIW)! This thread is really interesting as the whole idea would help to solve the biggest issue with my (currently stalled) project to integrate Xapian as a full-text search engine. Getting index scans used in all situations would drastically improve performance. eric ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] msg translation into sk_SK, Docs: SGML - XML
Having googled around I found this about Docbook to PDF conversion: http://www.linuxfocus.org/English/May2000/article152.shtml no sign of fop. I hope it helps and that I am not mistaken when I claim the format is docbook. Cheers Zoltan - Original Message - From: Karel Zak [EMAIL PROTECTED] To: Peter Eisentraut [EMAIL PROTECTED] Cc: BARTKO, Zoltan [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Friday, January 30, 2004 10:42 AM Subject: Re: [HACKERS] msg translation into sk_SK, Docs: SGML - XML On Thu, Jan 29, 2004 at 07:02:12PM +0100, Peter Eisentraut wrote: Peter E. works on XML docbook version of docs. I don't know if he wants to move directly to XML or uses on the fly conversion to XML by osx (sgml2xml). This conversion you try use by make testxml stuff in the doc/src/sgml/Makefile. I tested it and it works -- but for example conversion from XML to PDF by fop failed, but it's might be fop problem. The general consensus is that FOP is simply not there yet. Do you how idea how convert XML to fo or directly to pdf? Peter, what's your planns? Well, when people feel good about it, we can switch the stored format to XML. I'm not in a hurry, though, because what is there right now is I feel good about it. The important thing is support in Makefiles XML conversion to other formats like HTML, PDF and man. It's strange if after release almost nobody has idea how create PDF docs. almost equivalent. I've also tried out the po2xml thingy and it seems to work, but translating about 1 strings seems to be a daunting task. Be optimistic! ;-) Karel -- Karel Zak [EMAIL PROTECTED] http://home.zf.jcu.cz/~zakkr/ Information from NOD32 This message was checked by NOD32 Antivirus System for Linux Mail Server. http://www.nod32.com ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
[HACKERS] Sync vs. fsync during checkpoint
As some know, win32 doesn't have sync, and some are concerned that sync isn't reliable enough during checkpoint anyway. The trick is to somehow record all files modified since the last checkpoint, and open/fsync/close each one. My idea is to stat() each file in each directory and compare the modify time to determine if the file has been modified since the last checkpoint. I can't think of an easier way to efficiently collect all modified files. In this case, we let the file system keep track of it for us. However, on XP, I just tested if files that are kept open have their modification times modified, and it seems they don't. If I do: while : echo test sleep 5 done x I see the file size grow every 5 seconds, but I don't see the modification time change. Can someone confirm this? -- 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
Re: [HACKERS] Mixing threaded and non-threaded
On Jan 30, 2004, at 3:18 AM, Bruce Momjian wrote: Manfred Spraul wrote: Bruce Momjian wrote: Woh, as far as I know, any application should run fine with -lpthread, threaded or not. What OS are you on? This is the first I have heard of this problem. Perhaps we should try to figure out how other packages handle multithreaded/singlethreaded libraries? I'm looking at openssl right now, and openssl never links against libpthread: The caller is responsible for registering the locking primitives. Some other libraries, such as boost, always link against -lpthread when it is present. I don't think OpenSSL's example is a good one to follow. It's way too easy to forget to do that, and then your application is broken. You'll have weird crashes that will be hard to figure out. I think OpenSSL was made such because pthreads was not so common back in the day; they probably wanted to support other threading APIs. That's unnecessary now. Another reason might be to avoid the expense of locks when they are unnecessary. But also, I think that is not as necessary as it once was, particularly with modern systems like Linux+NPTL having locks cost virtually nothing when there is no contention. We perhaps don't need -lpthread for creating libpq, but only for ecpg. However, now that we have used thread locking for SIGPIPE, we are now calling pthread from libpq, but only 7.5. However, I still don't understand why the user is seeing a problem and what rewrite he thinks is necessary for his application because pthread is linked in. I'm 99% certain that any application will work with -lpthread on RedHat Linux. And 95% certain that's true on _any_ platform. There's no pthread_init() or anything; the distinction he was describing between a non-threaded application and a threaded application with only one thread doesn't exist as far as I know. And he mentioned that the deadlocks are occurring in a SIGCHLD handler. Since so few functions are async signal-safe (I doubt anything in libpq is), the code in question was broken before; the extra locking is just making it more obvious. Speaking of async signal-safe functions, pthread_getspecific() isn't specified to be (and thus PQinSend() and thus sigpipe_handler_ignore_send()). It's probably okay, but libpq is technically using undefined behavior according to SUSv3. Scott Lamb ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] [pgsql-hackers-win32] Sync vs. fsync during checkpoint
Bruce Momjian [EMAIL PROTECTED] writes: The trick is to somehow record all files modified since the last checkpoint, and open/fsync/close each one. My idea is to stat() each file in each directory and compare the modify time to determine if the file has been modified since the last checkpoint. This seems a complete non-starter, as stat() generally has at best one-second resolution on mod times, even if you assume that the kernel keeps mod time fully up-to-date at all times. In any case, it's difficult to believe that stat'ing everything in a database directory will be faster than keeping track of it for ourselves. regards, tom lane ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Mixing threaded and non-threaded
Scott Lamb wrote: Speaking of async signal-safe functions, pthread_getspecific() isn't specified to be (and thus PQinSend() and thus sigpipe_handler_ignore_send()). It's probably okay, but libpq is technically using undefined behavior according to SUSv3. Yikes. I never suspected pthread_getspecific() would not be signal safe because it is already thread safe, but I see the point that it is called in the current thread. Any ideas how to fix this? -- 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] [pgsql-hackers-win32] Sync vs. fsync during checkpoint
Tom Lane wrote: Bruce Momjian [EMAIL PROTECTED] writes: The trick is to somehow record all files modified since the last checkpoint, and open/fsync/close each one. My idea is to stat() each file in each directory and compare the modify time to determine if the file has been modified since the last checkpoint. This seems a complete non-starter, as stat() generally has at best one-second resolution on mod times, even if you assume that the kernel keeps mod time fully up-to-date at all times. In any case, it's difficult to believe that stat'ing everything in a database directory will be faster than keeping track of it for ourselves. Yes, we would have to have a slop factor and fsync anything more than one second before the last checkpoint. Any ideas on how to record the modified files without generating tones of output or locking contention? -- 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] Mixing threaded and non-threaded
On Fri, Jan 30, 2004 at 11:10:49AM -0600, Scott Lamb wrote: On Jan 30, 2004, at 3:18 AM, Bruce Momjian wrote: Manfred Spraul wrote: Bruce Momjian wrote: Woh, as far as I know, any application should run fine with -lpthread, threaded or not. What OS are you on? This is the first I have heard of this problem. Perhaps we should try to figure out how other packages handle multithreaded/singlethreaded libraries? I'm looking at openssl right now, and openssl never links against libpthread: The caller is responsible for registering the locking primitives. I don't think changing the linking approach is a good thing. But a mention in the documentation might be. We perhaps don't need -lpthread for creating libpq, but only for ecpg. However, now that we have used thread locking for SIGPIPE, we are now calling pthread from libpq, but only 7.5. However, I still don't understand why the user is seeing a problem and what rewrite he thinks is necessary for his application because pthread is linked in. I suspect the rewrite needed is to avoid doing Bad Things in the signal handler. I'm 99% certain that any application will work with -lpthread on RedHat Linux. And 95% certain that's true on _any_ platform. There's no pthread_init() or anything; the distinction he was describing between a non-threaded application and a threaded application with only one thread doesn't exist as far as I know. That may be true for any correctly written application, but it's certainly not true for any application. The distinction is, at the very least, that some system calls are wrapped with mutexes. And he mentioned that the deadlocks are occurring in a SIGCHLD handler. Since so few functions are async signal-safe (I doubt anything in libpq is), the code in question was broken before; the extra locking is just making it more obvious. I tend to agree. However, while it may have been broken before, it worked flawlessly in multiple production environments on several different operating systems for several years when not linked with pthread. Cheers, Steve ---(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] [pgsql-hackers-win32] Sync vs. fsync during checkpoint
Bruce Momjian [EMAIL PROTECTED] writes: Any ideas on how to record the modified files without generating tones of output or locking contention? What I've suggested before is that the bgwriter process can keep track of all files that it's written to since the last checkpoint, and fsync them during checkpoint (this would likely require giving the checkpoint task to the bgwriter instead of launching a separate process for it, but that doesn't seem unreasonable). Obviously this requires only local storage in the bgwriter process, and hence no contention. That leaves us still needing to account for files that are written directly by a backend process and not by the bgwriter. However, I claim that if the bgwriter is worth the cycles it's expending, cases in which a backend has to write out a page for itself will be infrequent enough that we don't need to optimize them. Therefore it would be enough to have backends immmediately sync any write they have to do. (They might as well use O_SYNC.) Note that backends need not sync writes to temp files or temp tables, only genuine shared tables. If it turns out that it's not quite *that* infrequent, a compromise position would be to keep a small list of files-needing-fsync in shared memory. Backends that have to evict pages from shared buffers add those files to the list; the bgwriter periodically removes entries from the list and fsyncs the files. Only if there is no room in the list does a backend have to fsync for itself. If the list is touched often enough that it becomes a source of contention, then the whole bgwriter concept is completely broken :-( Now this last plan does assume that an fsync applied by process X will write pages that were dirtied by process Y through a different file descriptor for the same file. There's been some concern raised in the past about whether we can assume that. If not, though, the simpler backends-must-sync-their-own-writes plan will still work. regards, tom lane ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] Why is it so easy to override -fno-strict-aliasing?
Tom Lane wrote: In config/c-compiler.m4 I read if test $ac_env_CFLAGS_set != set; then CFLAGS=$CFLAGS $pgac_cv_prog_cc_no_strict_aliasing fi This means that a configure operation as innocuous-looking as CFLAGS=-O3 ./configure will break the build on gcc = 3.3 because it will fail to supply -fno-strict-aliasing. I claim this is a lousy idea. We should drop the if-test and always add -fno-strict-aliasing if the compiler will take it. People who *really* know what they are doing can experiment with removing the switch from Makefile.global after configure, but I don't think it should be quite this easy to lose it. I agree. cheers andrew ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Mixing threaded and non-threaded
Bruce Momjian wrote: Scott Lamb wrote: Speaking of async signal-safe functions, pthread_getspecific() isn't specified to be (and thus PQinSend() and thus sigpipe_handler_ignore_send()). It's probably okay, but libpq is technically using undefined behavior according to SUSv3. Yikes. I never suspected pthread_getspecific() would not be signal safe because it is already thread safe, but I see the point that it is called in the current thread. Any ideas how to fix this? A few idea. When I ran a similar situation in my own code, my approach was to just add a comment to make the assumption explicit. It's quite possible the standard is just overly conservative. Some specific platforms - http://www.qnx.com/developer/docs/qnx_6.1_docs/neutrino/lib_ref/p/pthread_getspecific.html - mark it as being async signal-safe. Searching for pthread_getspecific signal on google groups turns up a bunch of other people who have run into this same problem. One person notes that it's definitely not safe on LinuxThreads if you use sigaltstack(). If your platform has SA_SIGINFO, you could - in theory - use the ucontext argument to see if that thread is in a PostgreSQL operation. But I doubt that's portable. You could just do a pthread_sigmask() before and after the pthread_setspecific() to guarantee that no SIGPIPE will arrive on that thread in that time. I think it's pretty safe to assume that as long as you're not doing a pthread_[gs]etspecific() on that same pthread_key_t, it's safe. There's one thread function that is guaranteed to be async signal-safe - sem_post(). (Though apparently older LinuxThreads on x86 fails to meet this assumption.) I'm not quite sure what you could do with that, but apparently there's something or they wouldn't have gone to the effort of making it so. Scott ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Mixing threaded and non-threaded
Scott Lamb wrote: You could just do a pthread_sigmask() before and after the pthread_setspecific() to guarantee that no SIGPIPE will arrive on that thread in that time. I think it's pretty safe to assume that as long as you're not doing a pthread_[gs]etspecific() on that same pthread_key_t, it's safe. Actually, thinking about this a bit more, that might not even be necessary. Is SIGPIPE-via-(read|write) synchronous or asynchronous? (I.e., is the SIGPIPE guaranteed to arrive during the offending system call?) I was thinking not, but maybe yes. I can't seem to find a straight answer. A lot of documents seem to confuse thread-directed and synchronous, when they're not quite the same thing. SIGALRM-via-alarm() is thread-directed but obviously asynchronous. ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] Question about indexes
Tom Lane kirjutas R, 30.01.2004 kell 16:48: Bruce Momjian [EMAIL PROTECTED] writes: Also, what does an in-memory bitmapped index look like? One idea that might work: a binary search tree in which each node represents a single page of the table, and contains a bit array with one bit for each possible item number on the page. You could not need more than BLCKSZ/(sizeof(HeapTupleHeaderData)+sizeof(ItemIdData)) bits in a node, or about 36 bytes at default BLCKSZ --- for most tables you could probably prove it would be a great deal less. You only allocate nodes for pages that have at least one interesting row. Another idea would be using bitmaps where we have just one bit per database page and do a seq scan but just over marked pages. Even when allocating them in full such indexes would occupy just 1/(8k*8bit) of the amount they describe, so index for 1GB table would be 1G/(8k*8bit) = 16 kilobytes (2 pages) Also, such indexes, if persistent, could also be used (together with FSM) when deciding placement of new tuples, so they provide a form of clustering. This would of course be most useful for data-warehouse type operations, where database is significantöy bigger than memory. And the seqscan over bitmap should not be done in simple page order, but rather in two passes - 1. over those pages which are already in cache (either postgresqls or systems (if we find a way to get such info from the system)) 2. in sequential order over the rest. I think this would represent a reasonable compromise between size and insertion speed. It would only get large if the indexscan output demanded visiting many different pages --- but at some point you could abandon index usage and do a sequential scan, so I think that property is okay. One case where almost full intermediate bitmap could be needed is when doing a star join or just AND of several conditions, where each single index spans a significant part of the table, but the result does not. A variant is to make the per-page bit arrays be entries in a hash table with page number as hash key. This would reduce insertion to a nearly constant-time operation, but the drawback is that you'd need an explicit sort at the end to put the per-page entries into page number order before you scan 'em. You might come out ahead anyway, not sure. Or we could try a true linear bitmap (indexed by page number times max-items-per-page plus item number) that's compressed in some fashion, probably just by eliminating large runs of zeroes. The difficulty here is that inserting a new one-bit could be pretty expensive, and we need it to be cheap. Perhaps someone can come up with other better ideas ... I have also contemplated a scenario, where we could use some not-quite-max power-of-2 bits-per-page linear bitmap and mark intra-page wraps (when we tried to mark a point past that not-quite-max number in a page) in high bit (or another bitmap) making info for that page folded. AN example would be setting bit 40 in 32-bits/page index - this would set bit 4031 and mark the page folded. When combining such indexes using AND or OR, we need some spcial handling of folded pages, but could still get non-folded (0) results out from AND of 2 folded pages if the bits are distributed nicely. -- Hannu ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] returning PGresult as xml
Peter Eisentraut kirjutas N, 29.01.2004 kell 19:31: Andrew Dunstan wrote: Peter: this looks very nice. What are your intentions with this code? Once we figure out how to handle the on-the-wire character set recoding when faced with XML documents (see separate thread a few weeks ago), I would like to finish it. Put it in contrib? Also, do you intend to implement the SQL/XML functions XMLElement, XMLForest, XMLAttributes, XMLConcat and XMLAgg? You have to implement these directly in the parser, which I'm not yet excited about. Why not use some standard parser ? libxml2 (www.xmlsoft.org) seems nice and is either available as a separate dynamic library or can also be (IIRC) configured to build with just the minimal needed functionality. --- Hannu ---(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] Mixing threaded and non-threaded
Scott Lamb wrote: You could just do a pthread_sigmask() before and after the pthread_setspecific() to guarantee that no SIGPIPE will arrive on that thread in that time. I think it's pretty safe to assume that as long as you're not doing a pthread_[gs]etspecific() on that same pthread_key_t, it's safe. I call pthread_setspecific() in the SIGPIPE handler. How sdoes pthread_sigmask() help me at that point? -- 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] Mixing threaded and non-threaded
Scott Lamb wrote: Scott Lamb wrote: You could just do a pthread_sigmask() before and after the pthread_setspecific() to guarantee that no SIGPIPE will arrive on that thread in that time. I think it's pretty safe to assume that as long as you're not doing a pthread_[gs]etspecific() on that same pthread_key_t, it's safe. Actually, thinking about this a bit more, that might not even be necessary. Is SIGPIPE-via-(read|write) synchronous or asynchronous? (I.e., is the SIGPIPE guaranteed to arrive during the offending system call?) I was thinking not, but maybe yes. I can't seem to find a straight answer. A lot of documents seem to confuse thread-directed and synchronous, when they're not quite the same thing. SIGALRM-via-alarm() is thread-directed but obviously asynchronous. SIGPIPE is a sychronous signal that is called during the read() in libpq. I am not sure what thread-directed is. -- 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] Question about indexes
Hannu Krosing [EMAIL PROTECTED] writes: Another idea would be using bitmaps where we have just one bit per database page and do a seq scan but just over marked pages. That seems a bit too lossy for me, but I really like your later idea about folding. Generalizing that a little, we can choose any fold point we like. We could allocate, say, one 32-bit word per page and set the (i mod 32) bit when item i is fingered by the index. After retrieving the heap page, we'd need to test all the valid rows that have item numbers matching a set bit mod 32. On typical tables (with circa 100 items per page) this would require testing only about 3 rows per page. ORing and ANDing of such bitmaps still works, with the understanding that it's lossy and you have to double check each retrieved tuple. If the fold point is above about 100, your idea of keeping track of whether we actually set any wrapped-around bits would become useful, but below that I think we'd just be wasting a bit. regards, tom lane ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] DBT-2 pulls PostgreSQL from CVS for STP
On 14 Jan, Jan Wieck wrote: Neil Conway wrote: Tom Lane [EMAIL PROTECTED] writes: This is a bug Jan introduced recently --- he forgot to modify the shared memory setup code to allow space for the new data structures used by ARC. Jan, would you mind fixing that soon? It's getting in people's way. Jan had asked that I include the fix for the bug in my bufmgr work (which I have), but considering that it will probably take me a while to get that into a state that is suitable for committing, it might make more sense for Jan to just commit the fix himself. K, will do Jan Ok, it did take me while to try another go at it, but it works. :) You can see some results against today's snapsnot here: http://khack.osdl.org/stp/287106/ And for review, you can see intructions on how to run your own here: http://developer.osdl.org/markw/stp_dbt2_howto.html Mark ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Question about indexes
Tom Lane kirjutas L, 31.01.2004 kell 01:02: Hannu Krosing [EMAIL PROTECTED] writes: Another idea would be using bitmaps where we have just one bit per database page and do a seq scan but just over marked pages. That seems a bit too lossy for me, I originally thought of it in context of data-warehousing and persistent bitmap indexes. there the use of these same bitmaps for clustering would un-lossify this approach. but I really like your later idea about folding. Generalizing that a little, we can choose any fold point we like. We could allocate, say, one 32-bit word per page and set the (i mod 32) bit when item i is fingered by the index. After retrieving the heap page, we'd need to test all the valid rows that have item numbers matching a set bit mod 32. On typical tables (with circa 100 items per page) this would require testing only about 3 rows per page. ORing and ANDing of such bitmaps still works, with the understanding that it's lossy and you have to double check each retrieved tuple. If the fold point is above about 100, your idea of keeping track of whether we actually set any wrapped-around bits would become useful, but below that I think we'd just be wasting a bit. Not only wasting bits, but also making the code hairier - we can't just do simple ANDs and ORs. -- Hannu ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Question about indexes
Tom Lane [EMAIL PROTECTED] writes: That seems a bit too lossy for me, but I really like your later idea about folding. Generalizing that a little, we can choose any fold point we like. We could allocate, say, one 32-bit word per page and set the (i mod 32) bit when item i is fingered by the index. After retrieving the heap page, we'd need to test all the valid rows that have item numbers matching a set bit mod 32. On typical tables (with circa 100 items per page) this would require testing only about 3 rows per page. ORing and ANDing of such bitmaps still works, with the understanding that it's lossy and you have to double check each retrieved tuple. That would make it really hard to ever clear the bits. What do you do when you vacuum and one of the tuples is no longer needed. You can't be sure you can clear the bit in the index because there could be multiple tuples represented by the bit being set. You would have to test the condition on the other tuples covered by the bit to see if it can be cleared. -- greg ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Question about indexes
Greg Stark [EMAIL PROTECTED] writes: Tom Lane [EMAIL PROTECTED] writes: ORing and ANDing of such bitmaps still works, with the understanding that it's lossy and you have to double check each retrieved tuple. That would make it really hard to ever clear the bits. We're speaking of in-memory bitmaps constructed on-the-fly here. You're right that it wouldn't work for persistent indexes, but I'm not very interested in that case at the moment ... regards, tom lane ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] Disaster!
Manfred Spraul [EMAIL PROTECTED] writes: That means open(); write(); sync(); could succeed, but the data is not stored on disk, correct? That would be true on any filesystem. Unless you throw an fsync() call in. With sync replaced by fsync then any filesystem ought to guarantee the data has reached disk by the time fsync returns. I think this is even true of NFS or AFS, though I wouldn't depend on it for my own data. -- greg ---(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] Copyright (C) 1996-2002
[EMAIL PROTECTED] (Jean-Michel POURE) stated in comp.databases.postgresql.hackers: Le Mardi 25 Novembre 2003 07:32, Randolf Richardson a écrit : I'm curious, has anyone consulted with a lawyer on this? Yes, the lawyer concluded that the number 2003 had been both registered as a trademark and a patented invention. Therefore, it is very likely that Humanity will be able to jump directly to the next non-registered digit, which is the year 200440033, called 'year of innovation', which also happens to be the price asked by the lawyer for bringing us into the future. Jean-Michel Heheh! I think you should ask that lawyer for your money back because his conclusions are questionable. Also, if the lawyer charged you for bringing you into the future, then that in itself is also questionable unless he/she is able to travel through time. ;-D -- Randolf Richardson - [EMAIL PROTECTED] Vancouver, British Columbia, Canada We are anti-spammers. You will confirm subscriptions. Resistance is futile. Please do not eMail me directly when responding to my postings in the newsgroups. ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] Disaster!
[EMAIL PROTECTED] (Greg Stark) stated in comp.databases.postgresql.hackers: Tom Lane [EMAIL PROTECTED] writes: Christopher Kings-Lynne [EMAIL PROTECTED] writes: FreeBSD 4.7/4.9 and the UFS filesystem Hm, okay, I'm pretty sure that that combination wouldn't report ENOSPC at close(). We need to fix the code to check close's return value, probably, but it seems we still lack a clear explanation of what happened to your database. The traditional Unix filesystems certainly don't return errors at close. Even NFS doesn't traditionally do so. I think NFSv3 can if the server disappears after the client obtains a lease on a piece of the file, but I'm not sure if ENOSPC is a possible failure mode. [sNip] Why shouldn't the close() function return an error? If an invalid file handle was passed to it, it most certainly should indicate this since it's always possible for a separate thread to close it first (or other reasons as well). -- Randolf Richardson - [EMAIL PROTECTED] Vancouver, British Columbia, Canada We are anti-spammers. You will confirm subscriptions. Resistance is futile. Please do not eMail me directly when responding to my postings in the newsgroups. ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] index scan with functional indexes -- solved
Dave Cramer wrote:
Interesting it works now, and the good news is it is *WAY* faster, this
might be able to speed up marc's doc search by orders of magnitude
this is searching 100536 rows
select * from url where fn_strrev(url) like fn_strrev('%beta12.html');
1.57ms
explain select * from url where url like '%beta12.html';
3310.38 ms
The nice thing about this is that you can create your query thusly:
SELECT * from table WHERE column like 'string' AND fn_strrev(column)
LIKE fn_strrev('string')
and, if you have both a standard index on column and a functional index
on fn_strrev(column), the query will be fast (well, as fast as the
pattern in question allows) as long as 'string' is anchored on either end.
I've implemented the 'locate' utility in Perl using a PG backend instead
of the standard locate database. I internally convert globs given as
arguments into LIKE strings, and with a functional index like that the
searches are now blazingly fast -- faster than the original 'locate'
utility. It has the added advantage that you can specify a file type
to further narrow the search (thus 'locate --type file core' will find
all regular files named 'core' in the database).
I'll be happy to share my code with anyone who's interested.
--
Kevin Brown [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] dump + restore didn't include schemas
Dan Langille [EMAIL PROTECTED] writes: I upgraded two servers today from 7.3.* to 7.4.1. In both cases, the schemas which existed in the original databases were not created in the new database. New issue? Known bug? New one on me. Look at the log output from when the dump was being restored. I suppose there must be an error message from the CREATE SCHEMA commands --- what is it? regards, tom lane ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] [pgsql-advocacy] PostgreSQL installation CD based on Morphix
OK. I've started working on the PostgreSQL-KNOPPIX English version. Could anyone tell me postgresql related events schedule? Are OSCON(June, Portland) and LinuxWorld(August, San Francisco) nearest? Josh Berkus [EMAIL PROTECTED] wrote: Jean-Michel, Morphix is an auto-bootable Debian GNU/Linux distribution based on Knoppix. What makes Morphix different is that the project has several graphical installers and wizards in preparation (written in plain C, using GTK-2 libraries and Glade-2) ... which could possibly be used to install GNU/Linux and PostgreSQL tools over MS Windows. Nice idea, but the Japanese PostgreSQL User's Group has already stolen a march on you. They have a Knoppix distribution with PostgreSQL, phpPgAdmin, PGAdminIII, phpBB and Linux+KDE already built ... we just need to get it localized to English. -- Josh Berkus Aglio Database Solutions San Francisco ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster -- NAGAYASU Satoshi [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] [pgsql-advocacy] PostgreSQL installation CD based on Morphix
Oops. Sorry I missed that thread. (Because I was working on my master thesis...) I'll read the past msgs before coming back this topic. Marc G. Fournier [EMAIL PROTECTED] wrote: On Sat, 24 Jan 2004, Satoshi Nagayasu wrote: OK. I've started working on the PostgreSQL-KNOPPIX English version. Satoshi ... Robert Bernier just reminded me that we currently have an English version sitting in our office ... Of course, I don't have it here with me, but maybe Robert can comment on what is on it before u spend alot of time recreating it? It might be something you two can collaborate on, if it doesn't contain everything your Japanese version already does? Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: [EMAIL PROTECTED] Yahoo!: yscrappy ICQ: 7615664 -- NAGAYASU Satoshi [EMAIL PROTECTED] ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] [pgsql-advocacy] PostgreSQL installation CD based on Morphix
I've read past thread and I know about new book from No Starch Press. Now, I need some comments about applications which should be included in such LiveCD. Which application is appealing for PostgreSQL promotions or demonstrations? Or which kind of applications (admin tools, middleware, languages, user apps) should be included? Any suggestions or recommendations? No Starch Press's KNOPPIX includes all of server-side stuffs, pgAdmin3 and pgaccess. Right? Satoshi Nagayasu [EMAIL PROTECTED] wrote: Oops. Sorry I missed that thread. (Because I was working on my master thesis...) I'll read the past msgs before coming back this topic. Marc G. Fournier [EMAIL PROTECTED] wrote: On Sat, 24 Jan 2004, Satoshi Nagayasu wrote: OK. I've started working on the PostgreSQL-KNOPPIX English version. Satoshi ... Robert Bernier just reminded me that we currently have an English version sitting in our office ... Of course, I don't have it here with me, but maybe Robert can comment on what is on it before u spend alot of time recreating it? It might be something you two can collaborate on, if it doesn't contain everything your Japanese version already does? Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: [EMAIL PROTECTED] Yahoo!: yscrappy ICQ: 7615664 -- NAGAYASU Satoshi [EMAIL PROTECTED] -- NAGAYASU Satoshi [EMAIL PROTECTED] ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] [pgsql-advocacy] PostgreSQL installation CD based on Morphix
Satoshi, The postgres, knoppix CD that I created last summer was compiled to work with plpgsql, plperl(u), plpythonu, pltcl(u). It has ODBC and JDBC drivers compiled into it too: I had some problems with Java initially but overcame it after I tinkered with the ant startup script. I recompiled the kernel to get the 'elephant' (does it have a name??) icon rather than 'tux' in the frame buffer as it booted up, I also changed the knoppix bootup background to that of a picture of a huge looking elephant. The desktop was redesigned to offer full documentation references using konquorer (html and pdf). The desktop also includes links to pgadmin3 and pgaccess. A link was installed that would invoke psql straight into the sample databases that I had included. The trick to making postgres work on the CD was quite trivial, I edited the init script to identify if it was reading itself off a CD installation and subsequently copied the entire database cluster over to the virtual drive. The postgres server also works after its been committed to the PC harddrive too using the knoppix hdinstall script. You will find a detailed article that I wrote on how to create a knoppix CD at the orielly site, http://linux.oreillynet.com/pub/a/linux/2003/11/20/knoppix.html . There are also references made to it off the knoppix users site and the linux show, http://www2.thelinuxshow.com/archives/2003/upcoming-2003-11-25.html among others. The article was rated by O'Reilly as among its top 5 for the month of November. The book's publishing date has been scheduled for late spring/early summer so I had always planned to going back and updating the CD such as maybe including pl/r. It became apparent that a postgres CD would be quite useful at OSCON since No Starch Press and O'Reilly have an existing business relationship. Since I already write for O'Reilly I thought would be interesting to see if I could kill several birds with one stone. regards Robert Satoshi Nagayasu wrote: I've read past thread and I know about new book from No Starch Press. Now, I need some comments about applications which should be included in such LiveCD. Which application is appealing for PostgreSQL promotions or demonstrations? Or which kind of applications (admin tools, middleware, languages, user apps) should be included? Any suggestions or recommendations? No Starch Press's KNOPPIX includes all of server-side stuffs, pgAdmin3 and pgaccess. Right? Satoshi Nagayasu [EMAIL PROTECTED] wrote: Oops. Sorry I missed that thread. (Because I was working on my master thesis...) I'll read the past msgs before coming back this topic. Marc G. Fournier [EMAIL PROTECTED] wrote: On Sat, 24 Jan 2004, Satoshi Nagayasu wrote: OK. I've started working on the PostgreSQL-KNOPPIX English version. Satoshi ... Robert Bernier just reminded me that we currently have an English version sitting in our office ... Of course, I don't have it here with me, but maybe Robert can comment on what is on it before u spend alot of time recreating it? It might be something you two can collaborate on, if it doesn't contain everything your Japanese version already does? ---(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] [PATCHES] v7.4.1 text_position() patch
Korea PostgreSQL Users' Group [EMAIL PROTECTED] writes: Hm. I don't think it can actually fail, because the wchar strings are zero-terminated. [ yes it can ] You're right. I was confused at first because I couldn't reproduce the problem, but then I realized it's because I'm running with CLOBBER_FREED_MEMORY enabled, so the junk beyond the end of the string won't match the other string. Will commit the patch. Thanks. regards, tom lane It's surprising that nobody noticed the bug until now. It seems it has been there since 7.3 days. I would like to make a back patch for 7.3-stable if nobody objects. BTW, I'm interested in Korea PostgreSQL Users' Group since I myself am a bord member of Japan PostgreSQL Users' Group. Please let me know if both users group could make some collaboration, such as having a seminar in Korea or in Japan. -- Tatsuo Ishii ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] [PATCHES] v7.4.1 text_position() patch
Tatsuo Ishii [EMAIL PROTECTED] writes: It's surprising that nobody noticed the bug until now. It seems it has been there since 7.3 days. I would like to make a back patch for 7.3-stable if nobody objects. No objection here. Note that I applied a minimal patch to the 7.4 branch, but a more extensive one with some cosmetic changes in HEAD. You probably want to copy the 7.4 change to 7.3. regards, tom lane ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
