Re: [pgsql-advocacy] [HACKERS] Increased company involvement
Another example is the recent patch to check if there are orphaned file system files. That was submitted, Tom had questions, I posted why I thought it was valid, and the patch is going in today. Anyone has the ability to argue their point and try to sway the community, and any member has the right to request a vote on a specific issue. I know so maintainig of PostgreSQL isn't easy. And it's normal so everybody wont to see commit of your patch. The comunication with core developers is best, but some times I have opinion so some patches are lost - for example my little patch SQLSTATE, .. I remeber situation one year ago with named params of plpgsql function. Patch waited half of year. I don't wont to be negative :-)). PostgreSQL did big progress. Really. And last modification of plpgsql helped my in work. But its human natural. I looking for others nows. I am expectant for 2PC, hiearch queries, and ... PostgreSQL isn't only sw for me, it's more like idol :-) Best Regards, Pavel Stehule ---(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: [pgsql-advocacy] [HACKERS] Increased company involvement
Bruce Momjian wrote: (Funny, no one says I have too much power. I will have to look into how to get some someday.) :-) I think you have power, too. :-) You have commited many patches that some other commiters didn't like that much and would rather not have applied themselves. All with some consensus from the community, of course. The reason, IMHO, that Tom is seen as someone with more power than others, is because of his intimate knowledge of postgresql and software design in general. Most of his proposals are very welcome to the community and nobody would be against those. And if there are objections, Tom will usually listen to valid criticism and adapt his work. Not all core members or regular patch submitters have agreed with all changes in the past, not even within this in-group. There are different opinions and it's not one who always wins. I believe there is quite a balance. For many changes and patches proposed, most of the rejections I have seen were based on lack of knowledge of either postgresql design or philosophy or bad software design in general. Of course its rather the in-group who defined the postgresql design and philosophy in the first place, but well, it is because of them that postgresql exists as what it is. Most of the hassles can be avoided by speaking up on hackers first and convince some one with good postgresql know-how to help you get your work on track. Best Regards, Michael Paesold ---(end of broadcast)--- TIP 8: explain analyze is your friend
[HACKERS] BTW, if anyone wants to work on it...
We've had a couple of cases recently where we had to advise DBAs to make manual changes in the system catalogs --- see for instance the 7.4.2 release notes or http://archives.postgresql.org/pgsql-announce/2005-05/msg1.php It'd be nicer if this sort of thing could be handled automatically by a software update. There are good reasons why it's not trivial, but having been burnt twice in recent memory, I'm starting to think it'd be worth setting up a mechanism to handle such changes automatically. Anyone up for working on it? 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] SPI bug.
Neil Conway wrote: We don't currently depend on C99, and not all platforms have a 64-bit datatype. In any case, I'm still unconvinced that using `int' and `long' in backend APIs is a problem. Using long means that you sometimes get a 32-bit value and sometimes a 64-bit value, I think we agree on that. There's no correlation between getting a 64-bit value and the fact that you run on a 64-bit platform since many 64-bit platforms treat a long as 32-bit. I think we agree on that too. If the objective behind using a long is that you get a data-type that followes the CPU register size then that objective is not met. No such data-type exists unless you use C99 intptr_t (an int that can hold a pointer). You could of course explicitly typedef a such in c.h but AFAICS, there is no such definition today. By using a long you will: a) maximize the differences of the SPI interfaces between platforms. b) only enable 64-bit resultset sizes on a limited range of 64-bit platforms. Wouldn't it be better if you: a) Minimized the differences between platforms. b) Made a decision to either use 32- or 64-bit resultset sizes (my preference would be the former) or to conseqently used 32-bit resultset sizes on 32-bit platforms and 64-bit resultset sizes on 64-bit platforms? Regards, Thomas Hallgren ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
[HACKERS] bitmap scan and explain analyze
I noticed that explain analyze emits a little bit funny reslut for bitmap scans: BitmapOr (cost=157.36..157.36 rows=18894 width=0) (actual time=9.406..9.406 rows=0 loops=1) Why actual rows=0? -- Tatsuo Ishii ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] Feature freeze date for 8.1
On 5/2/05, Heikki Linnakangas [EMAIL PROTECTED] wrote: What we can do in PostgreSQL is to introduce an application-level heartbeat. A simple Hello world message sent from server to client that the client would ignore would do the trick. Hmm, a quick-and-dirty implementation could be that a client issues LISTEN heartbeat; command, and there would be other client issuing NOTIFY heartbeat; every few minutes. I am not sure but this would probably make server send out these messages to the client, regardless of whether the client is doing something or not. Again, I am not sure. Ah, and probably so many NOTIFY messages wouldn't be very nice for system tables. Regards, Dawid ---(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] Feature freeze date for 8.1
On E, 2005-05-02 at 18:47 +0300, Heikki Linnakangas wrote: On Mon, 2 May 2005, Hannu Krosing wrote: It would be nice if I coud st up some timeut using keepalives (like ssh- s ProtocoKeepalives) and use similar timeouts on client and server. FWIW, I've been bitten by this problem twice with other applications. 1. We had a DB2 database with clients running in other computers in the network. A faulty switch caused random network outages. If the connection timed out and the client was unable to send it's request to the server, the client would notice that the connection was down, and open a new one. But the server never noticed that the connection was dead. Eventually, the maximum number of connections was reached, and the administrator had to kill all the connections manually. 2. We had a custom client-server application using TCP across a network. There was stateful firewall between the server and the clients that dropped the connection at night when there was no activity. After a couple of days, the server reached the maximum number of threads on the platform and stopped accepting new connections. In case 1, the switch was fixed. If another switch fails, the same will happen again. In case 2, we added an application-level heartbeat that sends a dummy message from server to client every 10 minutes. TCP keep-alive with a small interval would have saved the day in both cases. Unfortunately the default interval must be = 2 hours, according to RFC1122. On most platforms, including Windows and Linux, the TCP keep-alive interval can't be set on a per-connection basis. The ideal solution would be to modify the operating system to support it. Yep. I think this could be done for (our instance of) linux, but getting it into mainstream kernel, and then into all popular distros is a lot of effort. Going the ssh way (protocol level keepalives) might be way simpler. What we can do in PostgreSQL is to introduce an application-level heartbeat. A simple Hello world message sent from server to client that the client would ignore would do the trick. Actually we would need a round-trip indicator (some there-and-back message: A: do you copy 42 -- B: yes I copy 42), and not just send. The difficult part is what to do when one side happens to send the keepalive in the middle of actual data transfer ? move to packet oriented connections (UDP) and make different packet types independant of each other? -- Hannu Krosing [EMAIL PROTECTED] ---(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] ARCHIVE TABLES (was: possible TODO: read-only
On E, 2005-05-02 at 15:59 -0500, Jim C. Nasby wrote: Out of curiosity, what would be required to allow deletes (but not updates)? Deletes *are* the problem (and update is internally a delete+insert). Allowing deletes means no more selects from indexes only as tid can't be used for determining visibility. My thinking is that you'd want *some* way to be able to prune data. Since you won't want to store an entire XID/CID for the delete, I think it would be acceptable to keep a table of XID/CID values for deletes and just store a pointer to that table in the tuple header. This means you would be limited (perhaps severely) in the number of deletes you could issue between vacuums, but for this instance that seems perfectly reasonable. It might be worth using this same technique for inserts as well. If the only inserting into the table is from some nightly bulk process, you certainly don't need to store 4 (or is it 8) bytes of inserting transaction data with each tuple. The idea was using archive tables in partitioned tables if you need to prune data. Also, how does this allow for index scans without touching the heap? AFAIK when a tuple is inserted but not committed it is already in the index. You can check if tid (tuple id) is bigger than last valid (committed) tuple id in the table. -- Hannu Krosing [EMAIL PROTECTED] ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] ARCHIVE TABLES (was: possible TODO: read-only
On E, 2005-05-02 at 15:59 -0500, Jim C. Nasby wrote: Out of curiosity, what would be required to allow deletes (but not updates)? Perhaps a CLUSTER indexname ON tablename WHERE xxx could be used for that. That is a CLUSTER command that leaves out the tuples which do not satisfy xxx. -- Hannu Krosing [EMAIL PROTECTED] ---(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] ARCHIVE TABLES (was: possible TODO: read-only
On E, 2005-05-02 at 23:59 +0200, Jochem van Dieten wrote: On 5/2/05, Jim C. Nasby wrote: I think the advantages of both the ability to append to and delete from an archived table are largely negated with the design for table partitioning as emerging from the work of Simon e.a. on the bizgres list. True for delete, but not for append (see below) The advantage of being able to append would be negated by having a partitioned table where you archive certain partitions and all attempts to subsequently append to those partitions are redirected to the catch-all partition. If you can append to the table, it will get the advantage of index-only scans and space-saving headerless tuples from the start, not just after freezing it. Of course we could add a feature of 'closing' the archive table for appends at some point and then omit the tid checksm but I think the tid checks are so cheap that the added need to check if the tid comparison is needed will make this useless. For the delete case that would fit the most common usage pattern of an archive to periodically drop off historic data, is to simply drop an entire partition. Within such a partitioning framework a CLUSTER partitionname ARCHIVE operation that truly sets the data in that partition in stone might not be a totally outrageous concept :) The main use of archive tables would be for use as partitions in a partitioned table. But some big static fact tables could also benefit. The advantage of having the ability to append to such tables is mainly performance/storage one - you can create a large table with no per-tuple visibility info (no stored tuple header) from the start, without the hassle of reclustering it. Headerless tuples were not an original design target, but they do seem desirable for huge but narrow tables. -- Hannu Krosing [EMAIL PROTECTED] ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [pgsql-advocacy] [HACKERS] Increased company involvement
Am Montag, 2. Mai 2005 20:14 schrieb Bruce Momjian: I posted this compromise and no one replied so I thought everyone was OK with it. It gets it into CVS, but has a separate compile stage to deal with the recursive dependency problem. How will a separate compile stage work for actually building, say, RPM or Debian packages? The only way I can see is wrapping up the PostgreSQL distribution tarball a second time as a plphp source package and build from there, which seems quite weird. -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] BTW, if anyone wants to work on it...
We've had a couple of cases recently where we had to advise DBAs to make manual changes in the system catalogs --- see for instance the 7.4.2 release notes or http://archives.postgresql.org/pgsql-announce/2005-05/msg1.php It'd be nicer if this sort of thing could be handled automatically by a software update. There are good reasons why it's not trivial, but having been burnt twice in recent memory, I'm starting to think it'd be worth setting up a mechanism to handle such changes automatically. Anyone up for working on it? I suppose you want something a bit less trivial than this one, but if somebody has benefit from it, here's the script I've been using to patch my dbs. It's very trivial - error checking is dba-eyeballs, for example. But if there are lots of databases, at least it saves a few steps. A more complete solution would of course require some better error checking ;-) //Magnus patchpg.sh Description: patchpg.sh ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
[HACKERS] Regression tests
Are there any regression tests or unit tests beyond 'make check', or possibly benchmarks which not only measure performance but also verify that the results are correct? I have patches which I want to test under high load from multiple concurrent clients, so 'make check' isn't enough. Google has tons of hits for articles and RDBMS reviews that mention SuperSmack, but no hits for the actual software. DES -- Dag-Erling Smørgrav - [EMAIL PROTECTED] ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [pgsql-advocacy] [HACKERS] Increased company involvement
* Peter Eisentraut ([EMAIL PROTECTED]) wrote: Am Montag, 2. Mai 2005 20:14 schrieb Bruce Momjian: I posted this compromise and no one replied so I thought everyone was OK with it. It gets it into CVS, but has a separate compile stage to deal with the recursive dependency problem. How will a separate compile stage work for actually building, say, RPM or Debian packages? The only way I can see is wrapping up the PostgreSQL distribution tarball a second time as a plphp source package and build from there, which seems quite weird. More than a little ugly, no thanks, please don't... It should really be made to be buildable outside of the PostgreSQL source tree, depending only upon the server API (which is provided in a seperate Debian package which plphp could build-depend on). This is exactly how Slony will be packaged too.. From what I've gathered it sounds like the only issue with this is that it may not get updated when the server API changes? Are there other issues? Is there something it needs that isn't or can't be provided by a seperate server API package? (For those curious- my current plans are that slony will actually generate a couple differnet binary debs, slon, slonik and libpostgresql-slon or so. libpostgresql-slon will have the .so which is installed in the postgresql libdir, slon and slonik have their associated programs and supporting things (.sql scripts, etc)). Thanks, Stephen signature.asc Description: Digital signature
Re: [HACKERS] pg_locks needs a facelift
On Mon, May 02, 2005 at 02:12:33PM -0400, Merlin Moncure wrote: Well, there's nothing that says you have to actually refer to locks by name. When I proposed this what I proposed is that the userlock module provide a dedicated means to map a lock name to a lock number, and reserve one of the 'lock spaces' (the 16 bit number) for this use, just as one of them is currently reserved for locks based on OID. But I also can't think of any reason why lock names need to be persistent, so I imagine you could store a list of lock names in shared memory with no backing storage. Well, actually, as currently implemented the userlock module provides 48 bits of lock space but none of the bits are reserved for anything...interface functions which assign the lower 32 bits to oid are provided as a convenience. IIRC userlocks were first implemented in 1998 when the oid played a larger role, it is now quite rightly deprecated and my intention is to remove it from the userlock module. The new userlocks should be able to take advantage of refinements in the locktag structure and provide a full 64 bits to resolve the lock at the least. 64 bits is the magic number because it now works quite nicely with sequences. Could you be more specific about how a string based user lock system would be implemented? Merlin ---(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] Regression tests
Are there any regression tests or unit tests beyond 'make check', or possibly benchmarks which not only measure performance but also verify that the results are correct? I have patches which I want to test under high load from multiple concurrent clients, so 'make check' isn't enough. Google has tons of hits for articles and RDBMS reviews that mention SuperSmack, but no hits for the actual software. The whole point of make check is to check correctness, not performance. It has concurrent loading as well. Chris ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] Feature freeze date for 8.1
Hannu Krosing [EMAIL PROTECTED] writes: What we can do in PostgreSQL is to introduce an application-level heartbeat. A simple Hello world message sent from server to client that the client would ignore would do the trick. Actually we would need a round-trip indicator (some there-and-back message: A: do you copy 42 -- B: yes I copy 42), and not just send. No, a one-way message is sufficient. The reason is that once we've asked the TCP stack to send something, the customary timeouts before declaring the connection dead are far shorter than they are for keepalives. Also see the point that we must not assume that the client-side library can get control on short notice (or indeed any notice). I am a tad worried about the possibility that if the client does nothing for long enough, the TCP output buffer will fill causing the backend to block at send(). A permanently blocked backend is bad news from a performance point of view (it degrades the sinval protocol for everyone else). regards, tom lane ---(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] bitmap scan and explain analyze
Tatsuo Ishii [EMAIL PROTECTED] writes: Why actual rows=0? I couldn't think of any reasonably cheap way to count the actual rows (especially in the presence of lossy bitmaps), so I just punted. regards, tom lane ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [pgsql-advocacy] [HACKERS] Increased company involvement
Peter Eisentraut [EMAIL PROTECTED] writes: Am Montag, 2. Mai 2005 20:14 schrieb Bruce Momjian: I posted this compromise and no one replied so I thought everyone was OK with it. It gets it into CVS, but has a separate compile stage to deal with the recursive dependency problem. How will a separate compile stage work for actually building, say, RPM or Debian packages? The only way I can see is wrapping up the PostgreSQL distribution tarball a second time as a plphp source package and build from there, which seems quite weird. I think the idea is that plphp would be in our CVS, but would not be shipped as part of the main tarball, rather as its own separate tarball. 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
Re: [HACKERS] Feature freeze date for 8.1
-Original Message- From: Tom Lane [mailto:[EMAIL PROTECTED] Sent: Tuesday, May 03, 2005 9:31 AM To: Hannu Krosing Cc: Heikki Linnakangas; Neil Conway; Oliver Jowett; [EMAIL PROTECTED]; Peter Eisentraut; Alvaro Herrera; pgsql-hackers@postgresql.org Subject: Re: [HACKERS] Feature freeze date for 8.1 [...] I am a tad worried about the possibility that if the client does nothing for long enough, the TCP output buffer will fill causing the backend to block at send(). A permanently blocked backend is bad news from a performance point of view (it degrades the sinval protocol for everyone else). So use MSG_DONTWAIT or O_NONBLOCK on the keepalive packets. That won't stop the buffer from getting filled up, but if you get an EAGAIN while sending a keepalive packet, you know the client is either dead or really busy. __ David B. Held Software Engineer/Array Services Group 200 14th Ave. East, Sartell, MN 56377 320.534.3637 320.253.7800 800.752.8129 ---(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: [pgsql-advocacy] [HACKERS] Increased company involvement
On Tue, 3 May 2005, Tom Lane wrote: Peter Eisentraut [EMAIL PROTECTED] writes: Am Montag, 2. Mai 2005 20:14 schrieb Bruce Momjian: I posted this compromise and no one replied so I thought everyone was OK with it. It gets it into CVS, but has a separate compile stage to deal with the recursive dependency problem. How will a separate compile stage work for actually building, say, RPM or Debian packages? The only way I can see is wrapping up the PostgreSQL distribution tarball a second time as a plphp source package and build from there, which seems quite weird. I think the idea is that plphp would be in our CVS, but would not be shipped as part of the main tarball, rather as its own separate tarball. That is what I'm hoping for ... if it can be shipped as a seperate tarball, my arguments *against* including it become moot, since packagers (and ports) can have a nice small, quick to download package instead of having to re-download a 11MB file each time ... I don't mind if its *also* ship'd in the main distribution as well, I just want that 'quick to download since I already have the libraries/headers installed' package ... Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: [EMAIL PROTECTED] Yahoo!: yscrappy ICQ: 7615664 ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [pgsql-advocacy] [HACKERS] Increased company involvement
Stephen Frost wrote: * Peter Eisentraut ([EMAIL PROTECTED]) wrote: Am Montag, 2. Mai 2005 20:14 schrieb Bruce Momjian: I posted this compromise and no one replied so I thought everyone was OK with it. It gets it into CVS, but has a separate compile stage to deal with the recursive dependency problem. How will a separate compile stage work for actually building, say, RPM or Debian packages? The only way I can see is wrapping up the PostgreSQL distribution tarball a second time as a plphp source package and build from there, which seems quite weird. More than a little ugly, no thanks, please don't... Not really that ugly. It is just an extra compile step. Besides you don't have to package it just because it is in the Tarball. Sincerely, Joshua D. Drake Command Prompt, Inc. It should really be made to be buildable outside of the PostgreSQL source tree, depending only upon the server API (which is provided in a seperate Debian package which plphp could build-depend on). This is exactly how Slony will be packaged too.. From what I've gathered it sounds like the only issue with this is that it may not get updated when the server API changes? Are there other issues? Is there something it needs that isn't or can't be provided by a seperate server API package? (For those curious- my current plans are that slony will actually generate a couple differnet binary debs, slon, slonik and libpostgresql-slon or so. libpostgresql-slon will have the .so which is installed in the postgresql libdir, slon and slonik have their associated programs and supporting things (.sql scripts, etc)). Thanks, Stephen ---(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: [pgsql-advocacy] [HACKERS] Decision Process WAS: Increased company involvement
-Original Message- From: Andrew Dunstan [mailto:[EMAIL PROTECTED] Sent: Monday, May 02, 2005 7:05 PM To: [EMAIL PROTECTED] Cc: Dave Held; [EMAIL PROTECTED]; pgsql-hackers@postgresql.org Subject: Re: [pgsql-advocacy] [HACKERS] Decision Process WAS: Increased company involvement [...] I nat happy avout that last point - personally, I value most highly the views of those who contribute code or similar and least highly the views of those whose principal contribution is opinions. Maybe so, but if you were a new contributor, why would you write a bunch of code with no assurance that it would go anywhere? It seems wiser to invest your time familiarizing yourself with the ins and outs of the codebase and the coding style of patches by looking at other people's work. It also seems smarter to lurk and see what kinds of changes are likely to be considered. I doubt you would think highly of a newcomer that contributed code that was not in the style of the codebase and was for a feature not on the TODO list and that didn't get community buy-in first. But then, how do you get community buy-in if you don't contribute code, according to you? __ David B. Held Software Engineer/Array Services Group 200 14th Ave. East, Sartell, MN 56377 320.534.3637 320.253.7800 800.752.8129 ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [pgsql-advocacy] [HACKERS] Increased company involvement
Joshua D. Drake wrote: Not really that ugly. It is just an extra compile step. Besides you don't have to package it just because it is in the Tarball. Since you keep raising that point: Not packaging something is not a valid solution to something being hard to package. -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
[HACKERS] distributed database
hello there does postgresql support distributed database tq ---(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] distributed database
mohammad izwan ibrahim wrote: does postgresql support distributed database The answer is no, but please pick the correct mailing list for such questions in the future. -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] [PERFORM] Bad n_distinct estimation; hacks suggested?
Hi, Josh, Josh Berkus wrote: Yes, actually. We need 3 different estimation methods: 1 for tables where we can sample a large % of pages (say, = 0.1) 1 for tables where we sample a small % of pages but are easily estimated 1 for tables which are not easily estimated by we can't afford to sample a large % of pages. If we're doing sampling-based estimation, I really don't want people to lose sight of the fact that page-based random sampling is much less expensive than row-based random sampling. We should really be focusing on methods which are page-based. Would it make sense to have a sample method that scans indices? I think that, at least for tree based indices (btree, gist), rather good estimates could be derived. And the presence of a unique index should lead to 100% distinct values estimation without any scan at all. Markus ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Feature freeze date for 8.1
On Tue, 3 May 2005, Tom Lane wrote: I am a tad worried about the possibility that if the client does nothing for long enough, the TCP output buffer will fill causing the backend to block at send(). A permanently blocked backend is bad news from a performance point of view (it degrades the sinval protocol for everyone else). Do you mean this scenario: 1. client application doesn't empty its receive buffer (doesn't call read) 2. server keeps sending data 3. client receive buffer fills 4. server send buffer fills 5. server send blocks. Unfortunately there's no way to tell if the client is misbehaving or the network connection is slow or the client is too busy to handle the data fast enough. I guess we could increase the send buffer (can it be set per-connection?), but that only delays the problem. Does statement_timeout fire on that scenario? How about the new transaction_timeout option discussed in other threads? - Heikki ---(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-advocacy] Increased company involvement
Marc G. Fournier wrote: On Tue, 3 May 2005, Tom Lane wrote: I think the idea is that plphp would be in our CVS, but would not be shipped as part of the main tarball, rather as its own separate tarball. That is what I'm hoping for ... if it can be shipped as a seperate tarball, my arguments *against* including it become moot, since packagers (and ports) can have a nice small, quick to download package instead of having to re-download a 11MB file each time ... I don't mind if its *also* ship'd in the main distribution as well, I just want that 'quick to download since I already have the libraries/headers installed' package ... Any other PL's not currently in your CVS that you might consider to bring in while you're at it? Regards, Thomas Hallgren ---(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: [pgsql-advocacy] [HACKERS] Increased company involvement
Peter Eisentraut wrote: Am Montag, 2. Mai 2005 20:14 schrieb Bruce Momjian: I posted this compromise and no one replied so I thought everyone was OK with it. It gets it into CVS, but has a separate compile stage to deal with the recursive dependency problem. How will a separate compile stage work for actually building, say, RPM or Debian packages? The only way I can see is wrapping up the PostgreSQL distribution tarball a second time as a plphp source package and build from there, which seems quite weird. Well like many rpms it will have an external dependency. You must have perl installed to install plPerl. The main problem here is that you would need a base install of php at a minimum. The PHP installed would not need to support PostgreSQL at the time. In fact now that I think about it depending on how you did it, this doesn't effect PostgreSQl as much as it effects PHP. You could compile and install plPHP+PostgreSQL as long as PHP was installed regardless of the extensions that PHP supported at the time. So you wouldn't need to compile PostgreSQL twice but you may need to compile PHP twice. Once for plPHP and then once if you wanted PostgreSQL support. Sincerely, Joshua D. Drake Command Prompt, Inc. -- Your PostgreSQL solutions company - Command Prompt, Inc. 1.800.492.2240 PostgreSQL Replication, Consulting, Custom Programming, 24x7 support Managed Services, Shared and Dedication Hosting Co-Authors: plPHP, plPerlNG - http://www.commandprompt.com/ ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [pgsql-advocacy] [HACKERS] Increased company involvement
I don't mind if its *also* ship'd in the main distribution as well, I just want that 'quick to download since I already have the libraries/headers installed' package ... We could break out all of the pls at that point? Where if you downloaded postgresql-opt you would get plPHP, plPerl etc... Sincerely, Joshua D. Drake Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: [EMAIL PROTECTED] Yahoo!: yscrappy ICQ: 7615664 ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq -- Your PostgreSQL solutions company - Command Prompt, Inc. 1.800.492.2240 PostgreSQL Replication, Consulting, Custom Programming, 24x7 support Managed Services, Shared and Dedication Hosting Co-Authors: plPHP, plPerlNG - http://www.commandprompt.com/ ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
[HACKERS] A proper fix for the conversion-function problem
I tried disabling public EXECUTE access on the built-in conversion functions, as we recommended yesterday, and found that it has one small problem: the conversion regression test fails. The test is expecting that unprivileged users can create conversions, but since CREATE CONVERSION requires you to have execute permissions on the specified function, they can't if we do this. This leaves me thinking that the best fix for the back branches is the one [EMAIL PROTECTED] originally suggested: modify the signature for conversion functions to use INTERNAL instead of CSTRING. I haven't actually experimented with that yet, but will shortly. Going forward, though, I really think we need to revisit the API for conversion functions. It seems a bit silly to have the infrastructure to let ordinary users create conversions if they can't create the functions needed to support them. 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
Re: [HACKERS] [pgsql-advocacy] Increased company involvement
I don't mind if its *also* ship'd in the main distribution as well, I just want that 'quick to download since I already have the libraries/headers installed' package ... Any other PL's not currently in your CVS that you might consider to bring in while you're at it? /me heres the sound of the plJava trumpets :) Regards, Thomas Hallgren ---(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 -- Your PostgreSQL solutions company - Command Prompt, Inc. 1.800.492.2240 PostgreSQL Replication, Consulting, Custom Programming, 24x7 support Managed Services, Shared and Dedication Hosting Co-Authors: plPHP, plPerlNG - http://www.commandprompt.com/ ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] [pgsql-advocacy] Increased company involvement
On Tue, 3 May 2005, Thomas Hallgren wrote: Marc G. Fournier wrote: On Tue, 3 May 2005, Tom Lane wrote: I think the idea is that plphp would be in our CVS, but would not be shipped as part of the main tarball, rather as its own separate tarball. That is what I'm hoping for ... if it can be shipped as a seperate tarball, my arguments *against* including it become moot, since packagers (and ports) can have a nice small, quick to download package instead of having to re-download a 11MB file each time ... I don't mind if its *also* ship'd in the main distribution as well, I just want that 'quick to download since I already have the libraries/headers installed' package ... Any other PL's not currently in your CVS that you might consider to bring in while you're at it? Personally, if the above condition can be met, my objections for inclusion of anything into core would pretty much be voided, since it eliminates the requirement to download a 'monster tar ball' if you don't have to ... That doesn't say anyone else would have objections, only that I wouldn't ... Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: [EMAIL PROTECTED] Yahoo!: yscrappy ICQ: 7615664 ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [pgsql-advocacy] [HACKERS] Increased company involvement
On Tue, 2005-05-03 at 12:40, Peter Eisentraut wrote:
Joshua D. Drake wrote:
Not really that ugly. It is just an extra compile step. Besides
you don't have to package it just because it is in the Tarball.
Since you keep raising that point: Not packaging something is not a
valid solution to something being hard to package.
Is telling the rpm maintainers to go fix their rpm's an option? As has
been hashed out before, the only thing that makes plphp different from
other pl's is that some of the current packagers are taking shortcuts
with the packaging scripts which introduces dependency issues. IMHO what
is included in the postgresql cvs and what is included in the main
tarball for postgresql should not be dictated by outside packagers.
Robert Treat
--
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL
---(end of broadcast)---
TIP 6: Have you searched our list archives?
http://archives.postgresql.org
Re: [pgsql-advocacy] [HACKERS] Increased company involvement
Peter Eisentraut wrote: Joshua D. Drake wrote: Not really that ugly. It is just an extra compile step. Besides you don't have to package it just because it is in the Tarball. Since you keep raising that point: Not packaging something is not a valid solution to something being hard to package. Except that I don't consider it difficult. I do it all the time, it can be easily scripted. Sincerely, Joshua D. Drake -- Your PostgreSQL solutions company - Command Prompt, Inc. 1.800.492.2240 PostgreSQL Replication, Consulting, Custom Programming, 24x7 support Managed Services, Shared and Dedication Hosting Co-Authors: plPHP, plPerlNG - http://www.commandprompt.com/ ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [pgsql-advocacy] [HACKERS] Increased company involvement
On Tue, 3 May 2005, Joshua D. Drake wrote: I don't mind if its *also* ship'd in the main distribution as well, I just want that 'quick to download since I already have the libraries/headers installed' package ... We could break out all of the pls at that point? Where if you downloaded postgresql-opt you would get plPHP, plPerl etc... Optimally, you would get rid of -opt altogether, and leave it as the individual pl(s) ... the main purposes of the smaller tar balls is so that someone building a port (*BSDs) or a package (other OSs) would only need to download the component that applies to them, and someone installing from source, similar ... Another benefit would be the ability, for instance, of there being a plPHP project on pgfoundry, where, when a release is made, the tar file is copied up to there (by the project maintainer, not by me) ... this would be good to allow sub-projects like this to be able have their own discussion forms, bug tracking, etc ... while the main code is still maintained in the main source tree ... My primary desire is to avoid having to download several Meg of tar ball(s) in order to add a module to an existing server ... if that can be accomplished, then my main objection to adding things to the core CVS are eliminated ... Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: [EMAIL PROTECTED] Yahoo!: yscrappy ICQ: 7615664 ---(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: [pgsql-advocacy] [HACKERS] Increased company involvement
My primary desire is to avoid having to download several Meg of tar ball(s) in order to add a module to an existing server ... if that can be accomplished, then my main objection to adding things to the core CVS are eliminated ... I guess I don't see the problem of the PostgreSQL distribution being 11 megs, heck even 50 megs. I know that some places don't have the bandwidth we do but it only takes me about 90 seconds to download the distribution. Sincerely, Joshua D. Drake -- Your PostgreSQL solutions company - Command Prompt, Inc. 1.800.492.2240 PostgreSQL Replication, Consulting, Custom Programming, 24x7 support Managed Services, Shared and Dedication Hosting Co-Authors: plPHP, plPerlNG - http://www.commandprompt.com/ ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [pgsql-advocacy] [HACKERS] Decision Process WAS: Increased company
Dave Held wrote: -Original Message- From: Andrew Dunstan [mailto:[EMAIL PROTECTED] Sent: Monday, May 02, 2005 7:05 PM To: [EMAIL PROTECTED] Cc: Dave Held; [EMAIL PROTECTED]; pgsql-hackers@postgresql.org Subject: Re: [pgsql-advocacy] [HACKERS] Decision Process WAS: Increased company involvement [...] I nat happy avout that last point - personally, I value most highly the views of those who contribute code or similar and least highly the views of those whose principal contribution is opinions. Maybe so, but if you were a new contributor, why would you write a bunch of code with no assurance that it would go anywhere? People write code for lots of reasons, only some of which have directly to do with geting that code into the distributed product. But I digress :-) It seems wiser to invest your time familiarizing yourself with the ins and outs of the codebase and the coding style of patches by looking at other people's work. It also seems smarter to lurk and see what kinds of changes are likely to be considered. I doubt you would think highly of a newcomer that contributed code that was not in the style of the codebase and was for a feature not on the TODO list and that didn't get community buy-in first. I never suggested otherwise. But then, how do you get community buy-in if you don't contribute code, according to you? The surest path is to do things incrementally. And ask *lots* of questions. The bigger the development, and the more inexperienced you are, the more questions you should ask. Just getting the answers to yuour questions gets you some buyin (unless the consensus answer is don't do it). But the best bet is to build up credibility by doing small projects to start with. The postgres processes are nebulous, ill-defined, even. I don't see that as necessarily a bad thing. cheers andrew ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Feature freeze date for 8.1
Heikki Linnakangas [EMAIL PROTECTED] writes: Does statement_timeout fire on that scenario? How about the new transaction_timeout option discussed in other threads? Probably neither, since very likely you aren't in a transaction at all. I'd not expect the server to send these messages except when it's been idle for awhile, so statement_timeout is certainly irrelevant. BTW, the upthread proposal of just dropping the message (which is what O_NONBLOCK would do) doesn't work; it will lose encryption sync on SSL connections. regards, tom lane ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [pgsql-advocacy] [HACKERS] Increased company involvement
Robert Treat wrote: Is telling the rpm maintainers to go fix their rpm's an option? As has been hashed out before, the only thing that makes plphp different from other pl's is that some of the current packagers are taking shortcuts with the packaging scripts which introduces dependency issues. IMHO what is included in the postgresql cvs and what is included in the main tarball for postgresql should not be dictated by outside packagers. That wasn't my understanding of the previous discussion. Does not php require pg client support configured in at build time? cheers andrew ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [pgsql-advocacy] [HACKERS] Increased company involvement
Robert Treat [EMAIL PROTECTED] writes: Is telling the rpm maintainers to go fix their rpm's an option? As has been hashed out before, the only thing that makes plphp different from other pl's is that some of the current packagers are taking shortcuts with the packaging scripts which introduces dependency issues. IMHO what is included in the postgresql cvs and what is included in the main tarball for postgresql should not be dictated by outside packagers. Outside packagers? What makes you think PG RPMs are built by outside packagers? The PGDG RPMs are certainly built by us, and Red Hat's PG RPMs are built by somebody named Tom Lane, and last I heard Oliver Elphick was handling the Debian packaging. We have more control over those things than you might think. What we don't have control over is what the PHP people choose to put in their tarball ... and that means there's a circularity problem if we try to merge plphp. I think you are blaming the messengers. 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
Re: [pgsql-advocacy] [HACKERS] Increased company involvement
On Tuesday 03 May 2005 13:46, Andrew Dunstan wrote:
Robert Treat wrote:
Is telling the rpm maintainers to go fix their rpm's an option? As has
been hashed out before, the only thing that makes plphp different from
other pl's is that some of the current packagers are taking shortcuts
with the packaging scripts which introduces dependency issues. IMHO what
is included in the postgresql cvs and what is included in the main
tarball for postgresql should not be dictated by outside packagers.
That wasn't my understanding of the previous discussion. Does not php
require pg client support configured in at build time?
If your compiling it from source, it works similarly to perl... you only need
pg when compiling pg support into php, but you dont need tthis in for plphp.
The problem stems from things like the php rpm spec, which has a module
dependency on postgresql. This would create a circular dependency if we were
to put a dependency into the pg rpm spec for plphp.
I think the solution to this is to create a seperate rpm spec for php-pgsql
support, which would fall in line with how the php rpm packages are
distributed, but I'm not an expert in rpm specs...
--
Robert Treat
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL
---(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] Feature freeze date for 8.1
-Original Message- From: Tom Lane [mailto:[EMAIL PROTECTED] Sent: Tuesday, May 03, 2005 12:39 PM To: Heikki Linnakangas Cc: Hannu Krosing; Neil Conway; Oliver Jowett; [EMAIL PROTECTED]; Peter Eisentraut; Alvaro Herrera; pgsql-hackers@postgresql.org Subject: Re: [HACKERS] Feature freeze date for 8.1 [...] BTW, the upthread proposal of just dropping the message (which is what O_NONBLOCK would do) doesn't work; it will lose encryption sync on SSL connections. How about an optional second connection to send keepalive pings? It could be unencrypted and non-blocking. If authentication is needed on the ping port (which it doesn't seem like it would need to be), it could be very simple, like this: * client connects to main port * server authenticates client normally * server sends nonce token for keepalive authentication * client connects to keepalive port * client sends nonce token on keepalive port * server associates matching keepalive connection with main connection * if server does not receive matching token within a small timeout, no keepalive support enabled for this session __ David B. Held Software Engineer/Array Services Group 200 14th Ave. East, Sartell, MN 56377 320.534.3637 320.253.7800 800.752.8129 ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [pgsql-advocacy] [HACKERS] Increased company involvement
On Tue, 3 May 2005, Joshua D. Drake wrote: My primary desire is to avoid having to download several Meg of tar ball(s) in order to add a module to an existing server ... if that can be accomplished, then my main objection to adding things to the core CVS are eliminated ... I guess I don't see the problem of the PostgreSQL distribution being 11 megs, heck even 50 megs. I know that some places don't have the bandwidth we do but it only takes me about 90 seconds to download the distribution. Granted, we in the West are lucky ... but I know alot of ppl still on dialup, and I believe there are still alot of places in Europe (or is/was it just GB?) that pay per byte for their bandwidth ... even myself, at home, on a cable modem, have at times found downloads to be atrociously slow due to load n the network ... Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: [EMAIL PROTECTED] Yahoo!: yscrappy ICQ: 7615664 ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [pgsql-advocacy] [HACKERS] Increased company involvement
On Tue, 3 May 2005, Marc G. Fournier wrote: On Tue, 3 May 2005, Joshua D. Drake wrote: My primary desire is to avoid having to download several Meg of tar ball(s) in order to add a module to an existing server ... if that can be accomplished, then my main objection to adding things to the core CVS are eliminated ... I guess I don't see the problem of the PostgreSQL distribution being 11 megs, heck even 50 megs. I know that some places don't have the bandwidth we do but it only takes me about 90 seconds to download the distribution. Granted, we in the West are lucky ... but I know alot of ppl still on dialup, and I believe there are still alot of places in Europe (or is/was it just GB?) that pay per byte for their bandwidth ... even myself, at home, on a cable modem, have at times found downloads to be atrociously slow due to load n the network ... If anyone knows a *good* source for this sort of thing, please send me a URL, but a quick search on google finds: The market share for permanent connections continued to increase in December and now accounts for 39.4 per cent of all connections. This compares with a market share of 21.9 per cent a year before. http://www.i10.org.uk/pooled/articles/BF_NEWSART/view.asp?Q=BF_NEWSART_136457 Which, to me, indicates that ~60.6% of all connections are still dial-up (does ISDN count as a permanent connection?) ... but, I don't know where they are getting their #s from, so, as I said, if someone else can point me to better stats, please do ... Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: [EMAIL PROTECTED] Yahoo!: yscrappy ICQ: 7615664 ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [pgsql-advocacy] [HACKERS] Increased company involvement
Robert Treat wrote: On Tuesday 03 May 2005 13:46, Andrew Dunstan wrote: Robert Treat wrote: Is telling the rpm maintainers to go fix their rpm's an option? As has been hashed out before, the only thing that makes plphp different from other pl's is that some of the current packagers are taking shortcuts with the packaging scripts which introduces dependency issues. IMHO what is included in the postgresql cvs and what is included in the main tarball for postgresql should not be dictated by outside packagers. That wasn't my understanding of the previous discussion. Does not php require pg client support configured in at build time? If your compiling it from source, it works similarly to perl... you only need pg when compiling pg support into php, but you dont need tthis in for plphp. I suspect you are missing the point completely. It is in fact not like building perl at all. I just downloaded php-4.3.11 and got this from configure --help: --with-pgsql[=DIR] Include PostgreSQL support. DIR is the PostgreSQL base install directory, defaults to /usr/local/pgsql. You will not find any such parameter for building perl. Now it is true that you don't need this in for plphp. But if you want php to have pg client support you need pg built first. And no sane packager is going to build php twice. I understand (correct me if I'm wrong) that php is moving to get rid of this compile-time dependency - but it's not gone yet, to the best of my knowledge. cheers andrew ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [pgsql-advocacy] [HACKERS] Increased company involvement
Mitch Pirtle wrote: On 4/30/05, Jim C. Nasby [EMAIL PROTECTED] wrote: If money's not an issue anymore, can we get a bigger box to host pgfoundry on then? :) If you guys are planning on running Gforge, then you better make 'box' plural. Well we already run it :) For pgFoundry and you are correct it seems to be a bit of a pig. Our new machines should handle it better though. Sincerely, Joshua D. Drake -- Your PostgreSQL solutions company - Command Prompt, Inc. 1.800.492.2240 PostgreSQL Replication, Consulting, Custom Programming, 24x7 support Managed Services, Shared and Dedication Hosting Co-Authors: plPHP, plPerlNG - http://www.commandprompt.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
Re: [pgsql-advocacy] [HACKERS] Increased company involvement
* Robert Treat ([EMAIL PROTECTED]) wrote: If your compiling it from source, it works similarly to perl... you only need pg when compiling pg support into php, but you dont need tthis in for plphp. The problem stems from things like the php rpm spec, which has a module dependency on postgresql. This would create a circular dependency if we were to put a dependency into the pg rpm spec for plphp. I think the solution to this is to create a seperate rpm spec for php-pgsql support, which would fall in line with how the php rpm packages are distributed, but I'm not an expert in rpm specs... Just to point it out, Debian handles circular dependencies like these without too much difficulty. It's really only an issue when first building the various packages, and then you just build one without all the support initially, build the other, then rebuild the first with the support. So, in general, no, I don't think this should be justification for it being part of the main source tree and as a Debian maintainer would much prefer it be seperate and able to be compiled outside of the core Postgres tree.. Stephen signature.asc Description: Digital signature
[HACKERS] Bogus assertion in multixact.c?
There's an assertion in multixact.c, MultiXactIdExpand function, line 273: Assert(!TransactionIdEquals(multi, xid)); where multi is a MultiXactId and xid is a TransactionId. Isn't this bogus? If I understand the code correctly, multixactids and regular xids live in completely separate id spaces. Therefore a comparison between them makes no sense. - Heikki ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [pgsql-advocacy] [HACKERS] Increased company involvement
On Tue, 3 May 2005, Andrew Dunstan wrote: Robert Treat wrote: On Tuesday 03 May 2005 13:46, Andrew Dunstan wrote: Robert Treat wrote: Is telling the rpm maintainers to go fix their rpm's an option? As has been hashed out before, the only thing that makes plphp different from other pl's is that some of the current packagers are taking shortcuts with the packaging scripts which introduces dependency issues. IMHO what is included in the postgresql cvs and what is included in the main tarball for postgresql should not be dictated by outside packagers. That wasn't my understanding of the previous discussion. Does not php require pg client support configured in at build time? If your compiling it from source, it works similarly to perl... you only need pg when compiling pg support into php, but you dont need tthis in for plphp. I suspect you are missing the point completely. It is in fact not like building perl at all. I just downloaded php-4.3.11 and got this from configure --help: --with-pgsql[=DIR] Include PostgreSQL support. DIR is the PostgreSQL base install directory, defaults to /usr/local/pgsql. You will not find any such parameter for building perl. Now it is true that you don't need this in for plphp. But if you want php to have pg client support you need pg built first. And no sane packager is going to build php twice. Actually, if you look through FreeBSD ports, this is exactly what happens ... when you build /usr/ports/devel/php4, it builds a vanilla php, no modules ... if you want pgsql support, you go into /usr/ports/databases/php4-pgsql, and build that (which has a dependency on lang/php4) ... So, for plphp, a port would just have to install /usr/ports/lang/php4 to build, but would not necessarily build php4-pgsql ... it is done this way to avoid packagers having to build a monolithich contains everything php4 ... Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: [EMAIL PROTECTED] Yahoo!: yscrappy ICQ: 7615664 ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] Bogus assertion in multixact.c?
On Tue, May 03, 2005 at 09:33:30PM +0300, Heikki Linnakangas wrote: There's an assertion in multixact.c, MultiXactIdExpand function, line 273: Assert(!TransactionIdEquals(multi, xid)); where multi is a MultiXactId and xid is a TransactionId. Isn't this bogus? If I understand the code correctly, multixactids and regular xids live in completely separate id spaces. Therefore a comparison between them makes no sense. Well :-) actually that particular MultiXactId may be a TransactionId. (See the isMulti param, and comments at the beggining of the function.) This ugliness is there to support the notion of locking a tuple with either a TransactionId (non-contention case) or a MultiXactId (concurrent case.) We require MultiXactId to be equivalent to TransactionId anyway, because we store Multis on a tuple's Xmax. Congratulations for spotting that :-) (Are you using a source checker tool?) -- Alvaro Herrera ([EMAIL PROTECTED]) No hay cielo posible sin hundir nuestras raíces en la profundidad de la tierra(Malucha Pinto) ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [pgsql-advocacy] [HACKERS] Increased company involvement
* Tom Lane ([EMAIL PROTECTED]) wrote: Robert Treat [EMAIL PROTECTED] writes: Is telling the rpm maintainers to go fix their rpm's an option? As has been hashed out before, the only thing that makes plphp different from other pl's is that some of the current packagers are taking shortcuts with the packaging scripts which introduces dependency issues. IMHO what is included in the postgresql cvs and what is included in the main tarball for postgresql should not be dictated by outside packagers. Outside packagers? What makes you think PG RPMs are built by outside packagers? The PGDG RPMs are certainly built by us, and Red Hat's PG RPMs are built by somebody named Tom Lane, and last I heard Oliver Elphick was handling the Debian packaging. We have more control over those things than you might think. What we don't have control over is what the PHP people choose to put in their tarball ... and that means there's a circularity problem if we try to merge plphp. I think you are blaming the messengers. Oliver's not the only Debian person working on the PostgreSQL packages for Debian. Oliver certainly does a great deal of excellent work on the core PostgreSQL packages, I don't mean to claim otherwise, but Martin Pitt helps out a great deal with those, and various other packages are maintained by others (such as the php4-pgsql packages, which appear to currently be maintained by Steve Langasek, the libdbd-pg-perl packages which appear to be maintained by Raphael Hertzog, etc). Not arguing with you, you're right, Oliver's certainly one of the maintainers of the Debian core PostgreSQL packages, just not the only one. Thanks, Stephen signature.asc Description: Digital signature
Re: [HACKERS] Bogus assertion in multixact.c?
I wrote: Heikki Linnakangas [EMAIL PROTECTED] writes: Isn't this bogus? No. Note the comment immediately above, as well as the header comment for the function. OTOH, now that I think about it there's no reason whatever for that bizarre call convention. Let's split the function into two: one to expand an existing multixact, and one to make a multixact from two regular xids. 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] Bogus assertion in multixact.c?
Heikki Linnakangas [EMAIL PROTECTED] writes: There's an assertion in multixact.c, MultiXactIdExpand function, line 273: Assert(!TransactionIdEquals(multi, xid)); where multi is a MultiXactId and xid is a TransactionId. Isn't this bogus? No. Note the comment immediately above, as well as the header comment for the function. regards, tom lane ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [pgsql-advocacy] [HACKERS] Increased company involvement
Marc G. Fournier wrote: Now it is true that you don't need this in for plphp. But if you want php to have pg client support you need pg built first. And no sane packager is going to build php twice. Actually, if you look through FreeBSD ports, this is exactly what happens ... when you build /usr/ports/devel/php4, it builds a vanilla php, no modules ... if you want pgsql support, you go into /usr/ports/databases/php4-pgsql, and build that (which has a dependency on lang/php4) ... So, for plphp, a port would just have to install /usr/ports/lang/php4 to build, but would not necessarily build php4-pgsql ... it is done this way to avoid packagers having to build a monolithich contains everything php4 ... How ugly. [remaining comments unprintable] cheers andrew ---(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: [pgsql-advocacy] [HACKERS] Increased company involvement
* Marc G. Fournier ([EMAIL PROTECTED]) wrote: On Tue, 3 May 2005, Andrew Dunstan wrote: Now it is true that you don't need this in for plphp. But if you want php to have pg client support you need pg built first. And no sane packager is going to build php twice. Actually, if you look through FreeBSD ports, this is exactly what happens ... when you build /usr/ports/devel/php4, it builds a vanilla php, no modules ... if you want pgsql support, you go into /usr/ports/databases/php4-pgsql, and build that (which has a dependency on lang/php4) ... So, for plphp, a port would just have to install /usr/ports/lang/php4 to build, but would not necessarily build php4-pgsql ... it is done this way to avoid packagers having to build a monolithich contains everything php4 ... Indeed, Debian does this for a number of packages too, and I think we actually split out the PHP4 stuff into seperate 'source' packages in some cases which ends up making it not actually have to be a circular dependency (similar to Perl). Thanks, Stephen signature.asc Description: Digital signature
Re: [pgsql-advocacy] [HACKERS] Increased company involvement
Stephen Frost wrote: Just to point it out, Debian handles circular dependencies like these without too much difficulty. It's really only an issue when first building the various packages, and then you just build one without all the support initially, build the other, then rebuild the first with the support. I don't really believe that. People frequently do automated builds of the entire archive from scratch . There cannot be true circular build dependencies. That's the reason why the circular Qt - unixODBC dependency isn't resolved yet. Of course, on Debian, this whole discussion is moot anyway because the php-pgsql client module is built from an independent source package for other historic reasons. -- 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: [pgsql-advocacy] [HACKERS] Increased company involvement
* Marc G. Fournier ([EMAIL PROTECTED]) wrote: On Tue, 3 May 2005, Joshua D. Drake wrote: We could break out all of the pls at that point? Where if you downloaded postgresql-opt you would get plPHP, plPerl etc... Optimally, you would get rid of -opt altogether, and leave it as the individual pl(s) ... the main purposes of the smaller tar balls is so that someone building a port (*BSDs) or a package (other OSs) would only need to download the component that applies to them, and someone installing from source, similar ... I tend to like this approach. I think it'd also make it possible to have seperate Debian packages for the different languages more easily, which may be useful since they could more easily have different maintainers too. It'd also mean that you wouldn't have to have languages installed (or at least, on the system, perhaps not createlang'd) if you didn't want them, etc, etc. Stephen signature.asc Description: Digital signature
Re: [pgsql-advocacy] [HACKERS] Increased company involvement
On Tue, 3 May 2005, Andrew Dunstan wrote: Marc G. Fournier wrote: Now it is true that you don't need this in for plphp. But if you want php to have pg client support you need pg built first. And no sane packager is going to build php twice. Actually, if you look through FreeBSD ports, this is exactly what happens ... when you build /usr/ports/devel/php4, it builds a vanilla php, no modules ... if you want pgsql support, you go into /usr/ports/databases/php4-pgsql, and build that (which has a dependency on lang/php4) ... So, for plphp, a port would just have to install /usr/ports/lang/php4 to build, but would not necessarily build php4-pgsql ... it is done this way to avoid packagers having to build a monolithich contains everything php4 ... How ugly. [remaining comments unprintable] That's a matter of opinion ... in our environment, it means that clients can enable/disable PHP features on a per VM basis without having to build a new PHP binary for each ... *shrug* Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: [EMAIL PROTECTED] Yahoo!: yscrappy ICQ: 7615664 ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] Bogus assertion in multixact.c?
On Tue, May 03, 2005 at 02:48:20PM -0400, Tom Lane wrote: I wrote: Heikki Linnakangas [EMAIL PROTECTED] writes: Isn't this bogus? No. Note the comment immediately above, as well as the header comment for the function. OTOH, now that I think about it there's no reason whatever for that bizarre call convention. Let's split the function into two: one to expand an existing multixact, and one to make a multixact from two regular xids. No problem ... shall I write a patch, or did you do it already? -- Alvaro Herrera ([EMAIL PROTECTED]) No es bueno caminar con un hombre muerto ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [pgsql-advocacy] [HACKERS] Increased company involvement
* Peter Eisentraut ([EMAIL PROTECTED]) wrote: Stephen Frost wrote: Just to point it out, Debian handles circular dependencies like these without too much difficulty. It's really only an issue when first building the various packages, and then you just build one without all the support initially, build the other, then rebuild the first with the support. I don't really believe that. People frequently do automated builds of the entire archive from scratch . There cannot be true circular build dependencies. That's the reason why the circular Qt - unixODBC dependency isn't resolved yet. Of course, on Debian, this whole discussion is moot anyway because the php-pgsql client module is built from an independent source package for other historic reasons. No, it's exactly the case, and in fact I helped John Goerzen with exactly this issue of circular dependencies when first building the entire archive for amd64 about a year ago. Feel free to discuss it with him if you don't believe me for some reason. It may not be the case with this particular package but there are certinaly other instances (one that's fresh to mind is the X11 packages and groff, feel free to check it out yourself if you'd like; might be a little better than claiming others are wrong). Thanks, Stephen signature.asc Description: Digital signature
Re: [HACKERS] Bogus assertion in multixact.c?
Alvaro Herrera [EMAIL PROTECTED] writes: No problem ... shall I write a patch, or did you do it already? I'll take care of it --- wouldn't take much longer than applying someone else's patch anyway ... regards, tom lane ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [pgsql-advocacy] [HACKERS] Increased company involvement
That's a matter of opinion ... in our environment, it means that clients can enable/disable PHP features on a per VM basis without having to build a new PHP binary for each ... *shrug* Gentoo also does this :) Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: [EMAIL PROTECTED] Yahoo!: yscrappy ICQ: 7615664 -- Your PostgreSQL solutions company - Command Prompt, Inc. 1.800.492.2240 PostgreSQL Replication, Consulting, Custom Programming, 24x7 support Managed Services, Shared and Dedication Hosting Co-Authors: plPHP, plPerlNG - http://www.commandprompt.com/ ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [pgsql-advocacy] [HACKERS] Increased company involvement
Marc G. Fournier wrote: How ugly. [remaining comments unprintable] That's a matter of opinion ... in our environment, it means that clients can enable/disable PHP features on a per VM basis without having to build a new PHP binary for each ... *shrug* Different issue. You can do that on RH / Fedora too. 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: [pgsql-advocacy] [HACKERS] Increased company involvement
Marc G. Fournier wrote: On Tue, 3 May 2005, Marc G. Fournier wrote: On Tue, 3 May 2005, Joshua D. Drake wrote: My primary desire is to avoid having to download several Meg of tar ball(s) in order to add a module to an existing server ... if that can be accomplished, then my main objection to adding things to the core CVS are eliminated ... I guess I don't see the problem of the PostgreSQL distribution being 11 megs, heck even 50 megs. I know that some places don't have the bandwidth we do but it only takes me about 90 seconds to download the distribution. Granted, we in the West are lucky ... but I know alot of ppl still on dialup, and I believe there are still alot of places in Europe (or is/was it just GB?) that pay per byte for their bandwidth ... even myself, at home, on a cable modem, have at times found downloads to be atrociously slow due to load n the network ... If anyone knows a *good* source for this sort of thing, please send me a URL, but a quick search on google finds: The market share for permanent connections continued to increase in December and now accounts for 39.4 per cent of all connections. This compares with a market share of 21.9 per cent a year before. http://www.i10.org.uk/pooled/articles/BF_NEWSART/view.asp?Q=BF_NEWSART_136457 Which, to me, indicates that ~60.6% of all connections are still dial-up (does ISDN count as a permanent connection?) ... but, I don't know where they are getting their #s from, so, as I said, if someone else can point me to better stats, please do ... Better stats are in the same article Dial-up Internet connections continued to decrease, with a year on year fall to December 2004 of 20.1 per cent. The decrease from November to December 2004 was 3.1 per cent. Although it's hard to discern what this really says ( fell 20 % or is 20% , either way we can see a trend here ) Even if 60.6 % of all connections are dial up; what percentage of people downloading postgres are on dialup. The two numbers are not related. How come we have never seen anyone complain on the lists that the tarball is too big ( or have we ) This issue has come up before, and I opposed it then when the interfaces were removed from the main tarball. I really don't see the upside to reducing the size of the tarball at the expense of ease of use. Seems to me we are bending over backwards to make it easy for people with dial up connections to download our enterprise class database. Dave Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: [EMAIL PROTECTED] Yahoo!: yscrappy ICQ: 7615664 ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED]) -- Dave Cramer http://www.postgresintl.com 519 939 0336 ICQ#14675561 ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] Bogus assertion in multixact.c?
Never mind. multi is in effect a TransactionId in that code path, and thus the assertion makes sense. Sorry for the noise. On Tue, 3 May 2005, Heikki Linnakangas wrote: There's an assertion in multixact.c, MultiXactIdExpand function, line 273: Assert(!TransactionIdEquals(multi, xid)); where multi is a MultiXactId and xid is a TransactionId. Isn't this bogus? If I understand the code correctly, multixactids and regular xids live in completely separate id spaces. Therefore a comparison between them makes no sense. - Heikki - Heikki ---(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: [pgsql-advocacy] [HACKERS] Increased company involvement
On Tuesday 03 May 2005 13:51, Tom Lane wrote:
Robert Treat [EMAIL PROTECTED] writes:
Is telling the rpm maintainers to go fix their rpm's an option? As has
been hashed out before, the only thing that makes plphp different from
other pl's is that some of the current packagers are taking shortcuts
with the packaging scripts which introduces dependency issues. IMHO what
is included in the postgresql cvs and what is included in the main
tarball for postgresql should not be dictated by outside packagers.
Outside packagers? What makes you think PG RPMs are built by outside
packagers? The PGDG RPMs are certainly built by us, and Red Hat's PG
RPMs are built by somebody named Tom Lane, and last I heard Oliver
Elphick was handling the Debian packaging. We have more control over
those things than you might think. What we don't have control over is
what the PHP people choose to put in their tarball ... and that means
there's a circularity problem if we try to merge plphp. I think you
are blaming the messengers.
Don't get so defensive... I am well aware of the folks maintaining the pg
packages... I was talking about the php packagers.
--
Robert Treat
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL
---(end of broadcast)---
TIP 8: explain analyze is your friend
Re: [pgsql-advocacy] [HACKERS] Increased company involvement
On Tue, 3 May 2005, Dave Cramer wrote: How come we have never seen anyone complain on the lists that the tarball is too big ( or have we ) Because ppl are downloading the split distributions instead of the whole tarball ... *every* PostgreSQL related port in FreeBSD uses the split-dists (only downloads the base and opt packages) ... Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: [EMAIL PROTECTED] Yahoo!: yscrappy ICQ: 7615664 ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [pgsql-advocacy] [HACKERS] Increased company involvement
Marc G. Fournier wrote: On Tue, 3 May 2005, Dave Cramer wrote: How come we have never seen anyone complain on the lists that the tarball is too big ( or have we ) Because ppl are downloading the split distributions instead of the whole tarball ... *every* PostgreSQL related port in FreeBSD uses the split-dists (only downloads the base and opt packages) ... FreeBSD is a very small part of the OS planet compared to Linux and Win32. Look at how big the Win32 installer is ;) Sincerely, Joshua D. Drake -- Your PostgreSQL solutions company - Command Prompt, Inc. 1.800.492.2240 PostgreSQL Replication, Consulting, Custom Programming, 24x7 support Managed Services, Shared and Dedication Hosting Co-Authors: plPHP, plPerlNG - http://www.commandprompt.com/ ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [pgsql-advocacy] [HACKERS] Increased company involvement
So nobody has complained about the tarball being too big; yet we made it harder to use just in case someone might complain ? --dc-- Marc G. Fournier wrote: On Tue, 3 May 2005, Dave Cramer wrote: How come we have never seen anyone complain on the lists that the tarball is too big ( or have we ) Because ppl are downloading the split distributions instead of the whole tarball ... *every* PostgreSQL related port in FreeBSD uses the split-dists (only downloads the base and opt packages) ... Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: [EMAIL PROTECTED] Yahoo!: yscrappy ICQ: 7615664 -- Dave Cramer http://www.postgresintl.com 519 939 0336 ICQ#14675561 ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
[OT] Re: [pgsql-advocacy] [HACKERS] Increased company involvement
On Tue, 2005-05-03 at 14:26 -0400, Mitch Pirtle wrote: If you guys are planning on running Gforge, then you better make 'box' plural. I'm running MamboForge.net, and the poor thing is getting beat into the cold hard earth every day. We (Mambo) should really have two servers, at least to dedicate hardware to the database. Most of the servers in that class are dual Xeons as well - just as an indicator of what you are getting yourselves into ;-) Of course, Mitch is running the second largest GForge site on the planet (as far as I know) second only to https://helixcommunity.org/. Here's a list of them: http://gforge.org/docman/view.php/1/52/gforge-sites.html Yours, Tom Copeland ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Feature freeze date for 8.1
On Tue, 3 May 2005 13:02:46 -0500 Dave Held [EMAIL PROTECTED] wrote: How about an optional second connection to send keepalive pings? It could be unencrypted and non-blocking. If authentication is needed on the ping port (which it doesn't seem like itwould needto be), it could be very simple, like this: * client connects to main port * server authenticates client normally * server sends nonce token for keepalive authentication * client connects to keepalive port * client sends nonce token on keepalive port * server associates matching keepalive connection with main connection * if server does not receive matching token within a small timeout, no keepalive support enabled for this session Yes, this looks like good.But ; 1. Do client interfaces (ODBC,JDBC OLEDB etc) need to be changed ? 2. If a firewall is used, ppl need to know the second port number so mean that 2 parameters should be added to postgres the first is timeout value and the second is port number of the second port would be used for keepalive.. Best Regards, Adnan DURSUN ASRIN Bili?im Hiz.Ltd. ---(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] Regression tests
Christopher Kings-Lynne [EMAIL PROTECTED] writes: The whole point of make check is to check correctness, not performance. I understand that. It has concurrent loading as well. It doesn't stress the system anywhere near enough to reveal bugs in, say, the shared memory or semaphore code. DES -- Dag-Erling Smørgrav - [EMAIL PROTECTED] ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Feature freeze date for 8.1
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Tuesday, May 03, 2005 3:36 PM To: Dave Held; pgsql-hackers@postgresql.org Subject: Re: [HACKERS] Feature freeze date for 8.1 [...] Yes, this looks like good.But ; 1. Do client interfaces (ODBC,JDBC OLEDB etc) need to be changed ? Only if they want to support the keepalive mechanism. It should be purely optional. 2. If a firewall is used, ppl need to know the second port number so mean that 2 parameters should be added to postgres the first is timeout value and the second is port number of the second port would be used for keepalive.. Sounds fine to me. __ David B. Held Software Engineer/Array Services Group 200 14th Ave. East, Sartell, MN 56377 320.534.3637 320.253.7800 800.752.8129 ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] Feature freeze date for 8.1
Dave Held [EMAIL PROTECTED] writes: How about an optional second connection to send keepalive pings? It could be unencrypted and non-blocking. If authentication is needed on the ping port (which it doesn't seem like it would need to be), it could be very simple, like this: * client connects to main port * server authenticates client normally * server sends nonce token for keepalive authentication * client connects to keepalive port * client sends nonce token on keepalive port * server associates matching keepalive connection with main connection * if server does not receive matching token within a small timeout, no keepalive support enabled for this session This seems to have nothing whatever to do with the stated problem? regards, tom lane ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] Feature freeze date for 8.1
On 5/3/05, Dave Held [EMAIL PROTECTED] wrote: -Original Message- From: Tom Lane [mailto:[EMAIL PROTECTED] Sent: Tuesday, May 03, 2005 12:39 PM To: Heikki Linnakangas Cc: Hannu Krosing; Neil Conway; Oliver Jowett; [EMAIL PROTECTED]; Peter Eisentraut; Alvaro Herrera; pgsql-hackers@postgresql.org Subject: Re: [HACKERS] Feature freeze date for 8.1 [...] BTW, the upthread proposal of just dropping the message (which is what O_NONBLOCK would do) doesn't work; it will lose encryption sync on SSL connections. How about an optional second connection to send keepalive pings? It could be unencrypted and non-blocking. If authentication is needed on the ping port (which it doesn't seem like it would need to be), it could be very simple, like this: * client connects to main port * server authenticates client normally * server sends nonce token for keepalive authentication * client connects to keepalive port * client sends nonce token on keepalive port * server associates matching keepalive connection with main connection * if server does not receive matching token within a small timeout, no keepalive support enabled for this session This will not work through firewalls. Is it not possible for the server to test the current network connection with the client? ---(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] [PERFORM] Bad n_distinct estimation; hacks suggested?
Quoting Markus Schaber [EMAIL PROTECTED]: Hi, Josh, Josh Berkus wrote: Yes, actually. We need 3 different estimation methods: 1 for tables where we can sample a large % of pages (say, = 0.1) 1 for tables where we sample a small % of pages but are easily estimated 1 for tables which are not easily estimated by we can't afford to sample a large % of pages. If we're doing sampling-based estimation, I really don't want people to lose sight of the fact that page-based random sampling is much less expensive than row-based random sampling. We should really be focusing on methods which are page-based. Okay, although given the track record of page-based sampling for n-distinct, it's a bit like looking for your keys under the streetlight, rather than in the alley where you dropped them :-) How about applying the distinct-sampling filter on a small extra data stream to the stats collector? -- Engineers think equations approximate reality. Physicists think reality approximates the equations. Mathematicians never make the connection. ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] [PERFORM] Bad n_distinct estimation; hacks suggested?
Mischa, Okay, although given the track record of page-based sampling for n-distinct, it's a bit like looking for your keys under the streetlight, rather than in the alley where you dropped them :-) Bad analogy, but funny. The issue with page-based vs. pure random sampling is that to do, for example, 10% of rows purely randomly would actually mean loading 50% of pages. With 20% of rows, you might as well scan the whole table. Unless, of course, we use indexes for sampling, which seems like a *really good* idea to me -- --Josh Josh Berkus Aglio Database Solutions San Francisco ---(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] Feature freeze date for 8.1
-Original Message- From: Tom Lane [mailto:[EMAIL PROTECTED] Sent: Tuesday, May 03, 2005 4:20 PM To: Dave Held Cc: pgsql-hackers@postgresql.org Subject: Re: [HACKERS] Feature freeze date for 8.1 Dave Held [EMAIL PROTECTED] writes: How about an optional second connection to send keepalive pings? It could be unencrypted and non-blocking. If authentication is needed on the ping port (which it doesn't seem like it would need to be), it could be very simple, like this: * client connects to main port * server authenticates client normally * server sends nonce token for keepalive authentication * client connects to keepalive port * client sends nonce token on keepalive port * server associates matching keepalive connection with main connection * if server does not receive matching token within a small timeout, no keepalive support enabled for this session This seems to have nothing whatever to do with the stated problem? I thought the problem was a server process that loses a connection to a client sticking around and consuming resources. And then I thought a possible solution was to try to see if the client is still alive by sending it an occasional packet. And then I thought a new problem is sending packets to an unresponsive client and filling up the output buffer and blocking the server process. So it seems that a possible solution to that problem is to have a separate connection for keepalive packets that doesn't block and doesn't interfere with normal client/server communication. Now granted, it is possible that the primary connection could die and the secondary is still alive. So let's consider the likely failure modes: * physical network failure In this case, I don't see how the secondary could survive while the primary dies. * client hangs or dies If the client isn't reading keepalives from the server, eventually the server's send queue will fill and the server will see that the client is unresponsive. The only way the client could fail on the primary while responding on the secondary is if it makes the connections in different threads, and the primary thread crashes somehow. At that point, I would hope that the user would notice that the client has died and shut it down completely. Otherwise, the client should just not create a separate thread for responding to keepalives. * transient network congestion It's possible that a keepalive could be delayed past the expiration time, and the server would assume that the client is dead when it's really not. Then it would close the client's connection rather rudely. But then, since there's no reliable way to tell if a client is dead or not, your other option is to consume all your connections on maybe-dead clients. So what am I missing? __ David B. Held Software Engineer/Array Services Group 200 14th Ave. East, Sartell, MN 56377 320.534.3637 320.253.7800 800.752.8129 ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Feature freeze date for 8.1
Tom Lane [EMAIL PROTECTED] writes: Dave Held [EMAIL PROTECTED] writes: How about an optional second connection to send keepalive pings? It could be unencrypted and non-blocking. If authentication is needed on the ping port (which it doesn't seem like it would need to be), it could be very simple, like this: This seems to have nothing whatever to do with the stated problem? Yeah--one of the original scenarios was firewall drops DB connection because it's inactive. Pinging over a second socket does nothing to address this. If you want to make sure network connection X is up, testing network connection Y, which happens to be between the same two processes, is only helpful in a limited set of circumstances. -Doug ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Feature freeze date for 8.1
-Original Message- From: [EMAIL PROTECTED] [mailto:pgsql-hackers- [EMAIL PROTECTED] On Behalf Of Dave Held Sent: Tuesday, May 03, 2005 3:41 PM To: pgsql-hackers@postgresql.org Subject: Re: [HACKERS] Feature freeze date for 8.1 -Original Message- From: Tom Lane [mailto:[EMAIL PROTECTED] Sent: Tuesday, May 03, 2005 4:20 PM To: Dave Held Cc: pgsql-hackers@postgresql.org Subject: Re: [HACKERS] Feature freeze date for 8.1 Dave Held [EMAIL PROTECTED] writes: How about an optional second connection to send keepalive pings? It could be unencrypted and non-blocking. If authentication is needed on the ping port (which it doesn't seem like it would need to be), it could be very simple, like this: * client connects to main port * server authenticates client normally * server sends nonce token for keepalive authentication * client connects to keepalive port * client sends nonce token on keepalive port * server associates matching keepalive connection with main connection * if server does not receive matching token within a small timeout, no keepalive support enabled for this session This seems to have nothing whatever to do with the stated problem? I thought the problem was a server process that loses a connection to a client sticking around and consuming resources. And then I thought a possible solution was to try to see if the client is still alive by sending it an occasional packet. And then I thought a new problem is sending packets to an unresponsive client and filling up the output buffer and blocking the server process. So it seems that a possible solution to that problem is to have a separate connection for keepalive packets that doesn't block and doesn't interfere with normal client/server communication. Now granted, it is possible that the primary connection could die and the secondary is still alive. So let's consider the likely failure modes: * physical network failure In this case, I don't see how the secondary could survive while the primary dies. * client hangs or dies If the client isn't reading keepalives from the server, eventually the server's send queue will fill and the server will see that the client is unresponsive. The only way the client could fail on the primary while responding on the secondary is if it makes the connections in different threads, and the primary thread crashes somehow. At that point, I would hope that the user would notice that the client has died and shut it down completely. Otherwise, the client should just not create a separate thread for responding to keepalives. * transient network congestion It's possible that a keepalive could be delayed past the expiration time, and the server would assume that the client is dead when it's really not. Then it would close the client's connection rather rudely. But then, since there's no reliable way to tell if a client is dead or not, your other option is to consume all your connections on maybe-dead clients. So what am I missing? __ David B. Held Software Engineer/Array Services Group 200 14th Ave. East, Sartell, MN 56377 320.534.3637 320.253.7800 800.752.8129 1) Adding a separate connection means managing that connection, making sure it gets connected/disconnected at the right times, and that it can traverse the same firewalls as the primary connection. 2) You'd need another process or another thread to respond on the secondary connection. If it's another process, the primary process could die/hang while the keepalive process keeps working (or vice versa). If it's another thread, you are forcing all clients to support multithreading. ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] Feature freeze date for 8.1
Dave Held wrote: So it seems that a possible solution to that problem is to have a separate connection for keepalive packets that doesn't block and doesn't interfere with normal client/server communication. What does this do that TCP keepalives don't? (other than add extra connection management complexity..) -O ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [pgsql-advocacy] [HACKERS] Increased company involvement
On Tue, 3 May 2005, Dave Cramer wrote: So nobody has complained about the tarball being too big; yet we made it harder to use just in case someone might complain ? Made what harder to use? You don't like the split, download the full tar ball ... both options are available to you ... myself, I find my time better spent working on the end application, not download a bunch of docs and stuff that I don't need to install ... each to their own ... but, again, the options are avaialble to you ... Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: [EMAIL PROTECTED] Yahoo!: yscrappy ICQ: 7615664 ---(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: [pgsql-advocacy] [HACKERS] Increased company involvement
On Tue, 3 May 2005, Joshua D. Drake wrote: Marc G. Fournier wrote: On Tue, 3 May 2005, Dave Cramer wrote: How come we have never seen anyone complain on the lists that the tarball is too big ( or have we ) Because ppl are downloading the split distributions instead of the whole tarball ... *every* PostgreSQL related port in FreeBSD uses the split-dists (only downloads the base and opt packages) ... FreeBSD is a very small part of the OS planet compared to Linux and Win32. Look at how big the Win32 installer is ;) Agreed, but that is a binary distribution ... also, and this is based only one the impression I've gotten from the list(s), and not on actually trying it, doesn't it include 'multiple smaller packages' that you can either install all of, or pieces of? As to FreeBSD vs Linux ... I don't have enough experience with Linux and how the packages work over there, but I don't believe that if someone were to download/package a plphp SRPM (or package) that they would include the whole 11MB tar file, would they? Or would they just package up that component which is applicable and have dependencies on other packages? Hell, let's go at it from the other side of the coin ... you talk about how fast your connection is to download it ... but it has to come from somewhere ... which is more 'mirror friendly'? Making everyone download 11MB at a time for a, what would plPHP be, 100k directory structure, or give them a 50k compressed tar file to download to get the component they require? I'm basing that estimate on how big the existing pls are in the source tree, so I may be high/low on the real size of plphp ... The point is that *if* something can be build using existing libraries/headers on the machine, without requiring the full source tree to build it, then providing the option to the downloader/packager/port to get the smaller piece is A Good Thing ... the only person that has made a compelling argument why PLs should be in the core CVS *at this time* is Tom (as regards the API changing, and its generally easier for him to modify the PLs then having the maintainers learn the changes), and that makes sense ... but as far as packaging on our end is concerned, if we can split off 'stand alone distributions', then that is what we should be looking at doing ... Hell ... my dream is to see a libpq-version.tar.gz distribution so that I don't have to download the full server source code each time I want to install onto a client machine ... and one of these days I'll figure out how to do it ... Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: [EMAIL PROTECTED] Yahoo!: yscrappy ICQ: 7615664 ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] A proper fix for the conversion-function problem
I tried disabling public EXECUTE access on the built-in conversion functions, as we recommended yesterday, and found that it has one small problem: the conversion regression test fails. The test is expecting that unprivileged users can create conversions, but since CREATE CONVERSION requires you to have execute permissions on the specified function, they can't if we do this. This leaves me thinking that the best fix for the back branches is the one [EMAIL PROTECTED] originally suggested: modify the signature for conversion functions to use INTERNAL instead of CSTRING. I haven't actually experimented with that yet, but will shortly. Going forward, though, I really think we need to revisit the API for conversion functions. It seems a bit silly to have the infrastructure to let ordinary users create conversions if they can't create the functions needed to support them. Why? Since the functions need to be written in C language, ordinary users cannot make them anyway. Same thing can be said to CREATE TYPE. -- Tatsuo Ishii ---(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] [PERFORM] Bad n_distinct estimation; hacks suggested?
John, But doesn't an index only sample one column at a time, whereas with page-based sampling, you can sample all of the columns at once. Hmmm. Yeah, we're not currently doing that though. Another good idea ... -- --Josh Josh Berkus Aglio Database Solutions San Francisco ---(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] Regression tests
Dag-Erling Smørgrav wrote: It doesn't stress the system anywhere near enough to reveal bugs in, say, the shared memory or semaphore code. I agree -- I think we definitely need more tests for the concurrent behavior of the system. -Neil ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] inclusions WAS: Increased company involvement
Dave, all: This issue has come up before, and I opposed it then when the interfaces were removed from the main tarball. I really don't see the upside to reducing the size of the tarball at the expense of ease of use. Seems to me we are bending over backwards to make it easy for people with dial up connections to download our enterprise class database. Small tarball size isn't the *primary* reason for having our push-it-out-to-pgFoundry attitude, it's the *tertiary* reason. The main two reasons are: 1) If we start including everything that's useful, where do we stop? There are enough pg add-ins to fill a CD -- 200 projects on GBorg and pgFoundry and others elsewhere. And some of them probably conflict with each other. Any decision to include some projects and not others will alienate people and possibly be a mis-evaluation; the libpq++/libpqxx mistake comes to mind. 2) As long as we're using CVS, the only way to organize autonomous project teams that have authority over their special areas but no ability to change central code is to push out projects to separate CVS trees. From my perspective, putting together a coherent distribution of PostgreSQL with all the add-ins you want is the job of commercial distributors and possibly OSS projects like Bizgres. -- --Josh Josh Berkus Aglio Database Solutions San Francisco ---(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] inclusions WAS: Increased company involvement
Josh Berkus said: Dave, all: This issue has come up before, and I opposed it then when the interfaces were removed from the main tarball. I really don't see the upside to reducing the size of the tarball at the expense of ease of use. Â Seems to me we are bending over backwards to make it easy for people with dial up connections to download our enterprise class database. Small tarball size isn't the *primary* reason for having our push-it-out-to-pgFoundry attitude, it's the *tertiary* reason. The main two reasons are: 1) If we start including everything that's useful, where do we stop? There are enough pg add-ins to fill a CD -- 200 projects on GBorg and pgFoundry and others elsewhere. And some of them probably conflict with each other. Any decision to include some projects and not others will alienate people and possibly be a mis-evaluation; the libpq++/libpqxx mistake comes to mind. 2) As long as we're using CVS, the only way to organize autonomous project teams that have authority over their special areas but no ability to change central code is to push out projects to separate CVS trees. From my perspective, putting together a coherent distribution of PostgreSQL with all the add-ins you want is the job of commercial distributors and possibly OSS projects like Bizgres. This water-torture campaign is disappointing. How many projects on gborg have any active maintenance? Our community is still small - we can ill afford fragmentation. Tom and others have already pointed out the good technical reasons for not divorcing PLs at least from the core code. I was not around at the time of the libpq++/libpqxx issue. But, honestly, fear of making a wrong decision should not be a reason not to make one. As for CVS - if we can't do development the way we want using it then it's time to replace it. I have been convinced for quite a while that it is living on borrowed time, but I am far less certain about what should be used to replace it. But making macro content decisions on the basis of what we can do with CVS is just crazy. cheers andrew ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] pg_locks needs a facelift
On Tue, May 03, 2005 at 10:22:08AM -0400, Merlin Moncure wrote: On Mon, May 02, 2005 at 02:12:33PM -0400, Merlin Moncure wrote: Well, there's nothing that says you have to actually refer to locks by name. When I proposed this what I proposed is that the userlock module provide a dedicated means to map a lock name to a lock number, and reserve one of the 'lock spaces' (the 16 bit number) for this use, just as one of them is currently reserved for locks based on OID. But I also can't think of any reason why lock names need to be persistent, so I imagine you could store a list of lock names in shared memory with no backing storage. Well, actually, as currently implemented the userlock module provides 48 bits of lock space but none of the bits are reserved for anything...interface functions which assign the lower 32 bits to oid are provided as a convenience. IIRC userlocks were first implemented in If I remember the docs correctly, it specifically mentions that one of the 16 bit values is used for the OID mapping. That value could be 0, I don't know, but the point is that anyone using userlock would naturally stay away from that range. 1998 when the oid played a larger role, it is now quite rightly deprecated and my intention is to remove it from the userlock module. I wish you wouldn't since http://rrs.decibel.org uses it. The new userlocks should be able to take advantage of refinements in the locktag structure and provide a full 64 bits to resolve the lock at the least. 64 bits is the magic number because it now works quite nicely with sequences. Could you be more specific about how a string based user lock system would be implemented? My thought is to include a lookup table in the module that would correlate text names to lock numbers. For those who don't care about performance, they could just aquire and release locks with a function that accepts a text name. If performance was an issue, they could lookup the lock number/ID for a text name and store that value. I also don't see any reason not to set aside a range of numbers as being intended for general use, and specifying that named locks would never use a number in that range. If you're going to go to 64 bit locks I suggest setting aside the range of 0 to 0x00ff (that is 48 bits, right? :) for backwards compatability, and also carving out a small chunk for use by other defined access methods (such as named locks and OIDs). That way if someone else thinks of an interesting way to refer to locks it can be added without worrying about colliding with locks used by existing software. BTW, the reason I'm so worried about lock number collisions is that the application I use them in is designed to run in an existing PostgreSQL database, which could easily be using userlocks of it's own. I want to do everything possible to ensure I don't conflict with anything else in the cluster (locks are cluster-wide, right?), so I use the OID of the function that aquires the lock. But of course that OID could end up duplicated, so I'd much rather be able to use a named lock which is almost guaranteed to be unique (unless someone else decides 'rrs.decibel.org: update()' makes a great lock name...) -- Jim C. Nasby, Database Consultant [EMAIL PROTECTED] Give your computer some brain candy! www.distributed.net Team #1828 Windows: Where do you want to go today? Linux: Where do you want to go tomorrow? FreeBSD: Are you guys coming, or what? ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] A proper fix for the conversion-function problem
Tatsuo Ishii [EMAIL PROTECTED] writes: Going forward, though, I really think we need to revisit the API for conversion functions. It seems a bit silly to have the infrastructure to let ordinary users create conversions if they can't create the functions needed to support them. Why? Since the functions need to be written in C language, ordinary users cannot make them anyway. Same thing can be said to CREATE TYPE. Isn't that a circular argument? If the API were not deliberately designed to make it C-only, you could usefully code conversions in string-hacking-friendly languages like Perl. I'd really like to simplify the conversion function signature to something like convert(bytea) returns bytea or possibly convert(cstring) returns cstring depending on whether you think that it's important to be able to pass zero bytes transparently. (The current encoding infrastructure seems pretty confused about that point --- there are null-terminated strings in some places and counts in others. Are there any encodings we care about that require embedded zero bytes?) 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
Re: [HACKERS] [PERFORM] Bad n_distinct estimation; hacks suggested?
Quoting Josh Berkus josh@agliodbs.com: Mischa, Okay, although given the track record of page-based sampling for n-distinct, it's a bit like looking for your keys under the streetlight, rather than in the alley where you dropped them :-) Bad analogy, but funny. Bad analogy? Page-sampling effort versus row-sampling effort, c'est moot. It's not good enough for stats to produce good behaviour on the average. Straight random sampling, page or row, is going to cause enough untrustworthy engine behaviour,for any %ages small enough to allow sampling from scratch at any time. I'm curious what the problem is with relying on a start-up plus incremental method, when the method in the distinct-sampling paper doesn't degenerate: you can start when the table is still empty. Constructing an index requires an initial full scan plus incremental update; what's the diff? Unless, of course, we use indexes for sampling, which seems like a *really good* idea to me distinct-sampling applies for indexes, too. I started tracking the discussion of this a bit late. Smart method for this is in VLDB'92: Gennady Antoshenkov, Random Sampling from Pseudo-ranked B+-trees. I don't think this is online anywhere, except if you have a DBLP membership. Does nybod else know better? Antoshenkov was the brains behind some of the really cool stuff in DEC Rdb (what eventually became Oracle). Compressed bitmap indices, parallel competing query plans, and smart handling of keys with hyperbolic distributions. -- Engineers think equations approximate reality. Physicists think reality approximates the equations. Mathematicians never make the connection. ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] A proper fix for the conversion-function problem
Are there any encodings we care about that require embedded zero bytes? UTF-8 does! ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] inclusions WAS: Increased company involvement
On Tue, 2005-05-03 at 18:06 -0700, Josh Berkus wrote: 1) If we start including everything that's useful, where do we stop? There are enough pg add-ins to fill a CD -- 200 projects on GBorg and pgFoundry and others elsewhere. And some of them probably conflict with each other. Any decision to include some projects and not others will alienate people and possibly be a mis-evaluation; the libpq++/libpqxx mistake comes to mind. Mmm, just think of it. If enough projects get into core maybe, just maybe, pg could compete with mozilla for the longest build time. Wouldn't that be nice. ;) [snip some stuff that I agree with] With regards to PLs, there is a good argument for having them in core: the volatility of the backend's APIs make it difficult to externally maintain. I know this is the case, first hand. Although, if dynamically loaded extensions are to be allowed, I think that that volatility should be seen as a problem, and not so much as a reason to keep things in the same tree. While I understand that it's likely to be difficult to give interversion [source] compatibility without sacrificing general improvement, I think it would be a good goal to have. ... I asked on IRC and I'm still curious, does PG have a API styling standard/guide? I see formatting and info about error messages, but nothing about function/global/typedef naming. -- Regards, James William Pye ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] A proper fix for the conversion-function problem
On 2005-05-04, John Hansen [EMAIL PROTECTED] wrote: Are there any encodings we care about that require embedded zero bytes? UTF-8 does! nonsense -- Andrew, Supernews http://www.supernews.com - individual and corporate NNTP services ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] pg_locks needs a facelift
Jim C. Nasby [EMAIL PROTECTED] writes: On Tue, May 03, 2005 at 10:22:08AM -0400, Merlin Moncure wrote: 1998 when the oid played a larger role, it is now quite rightly deprecated and my intention is to remove it from the userlock module. I wish you wouldn't since http://rrs.decibel.org uses it. Don't worry, I'll veto any immediate removal of functionality ;-) The correct way to handle this is to add some better userlock functionality and deprecate what's there. We can remove the crufty stuff in a release or three after it's been officially deprecated ... but there is no reason to remove it immediately. It won't conflict with a better version, just exist alongside. regards, tom lane ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] inclusions WAS: Increased company involvement
Andrew, I was not around at the time of the libpq++/libpqxx issue. But, honestly, fear of making a wrong decision should not be a reason not to make one. OK, *you* choose. I'm getting a little annoyed with how many people tell me oh, it should be easy to pick the stuff to include with standard PostgreSQL, and then expect core to do the choosing. Well, it's not easy, and core made choices. If you don't like them, then make a proposal, including a set of objective criteria that can be used to evaluate future projects -- and even to evaluate when to drop one. Apache does this; they have a 5-step process for accepted projects that took Brian co a year to work out. And the process has its cost; evaluation of acceptance is highly political and not infrequently results in people getting pissed off and/or impatient with the bureaucracy and leaving Apache to start independent projects. And even Apache doesn't tar up everything in one big package; mod_perl, geronimo, PHP, etc. are all separate. The advantage of a small kernel approach is the independence it gives add-in projects. You can start a pgFoundry project based on a weekend's enthusiasm; add whomever you want, use whatever OSS license you want, release on your own schedule. It means that add-in developers can prove the usefulness of their code by demonstration rather than having to meet some qualification process. Look at other large projects with lots of options. Apache, Perl, Linux, Java, emacs, KDE, etc., all of them strike a balance between including stuff and leaving stuff as add-ins (some more narrowly than others), and exclude a lot of popular and useful stuff on a variety of criteria. Our current balance is on the minimalist side, and somewhat arbitrary if you look at the /contrib directory. If you think there's a better balance, propose it. Seriously. As for CVS - if we can't do development the way we want using it then it's time to replace it. I have been convinced for quite a while that it is living on borrowed time, but I am far less certain about what should be used to replace it. But making macro content decisions on the basis of what we can do with CVS is just crazy. Again, you're saying that you don't have a solution but you think it should be fixed. Great. I think it should be fixed, too. Afaik, there is *no* versioning system that allows for both completely independent control of branches and directories while at the same time allowing for a cohesive build. Maybe BK does, that would explain why Linus liked it so much. I, personally, would *love* to find a way for the drivers to be included with the core build while still letting the various teams -- particularly JDBC and Python -- have control over their own groups. And I think we need a way for add-ins to build in a completely integrated way with the backend, including building in docs. But these are not technically easy problems. (I hope people understand here that I'm speaking for me, personally) -- Josh Berkus Aglio Database Solutions San Francisco ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] inclusions WAS: Increased company involvement
Andrew Dunstan [EMAIL PROTECTED] writes: As for CVS - if we can't do development the way we want using it then it's time to replace it. CVS's capabilities (or lack of same) are completely unrelated to the matter in hand. What we are talking about is packaging, ie what should sensibly go out in the same shipped tarball. regards, tom lane ---(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] A proper fix for the conversion-function problem
John Hansen [EMAIL PROTECTED] writes: Are there any encodings we care about that require embedded zero bytes? UTF-8 does! Surely not. Were you thinking of UTF-16 or UCS-2 or whatever it's called? 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
