Re: [HACKERS] Feature freeze date for 8.1
Any chance one of you fine people could start another thread? This has very little to do with "Feature freeze date for 8.1"... Thanks, Best Regards, Simon Riggs ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Regression tests
On Wed, 2005-05-04 at 10:56 +1000, Neil Conway wrote: > 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. > Yes, very much agree. Contributions in that area would be most welcome. Best Regards, Simon Riggs ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] inclusions WAS: Increased company involvement
Tom Lane <[EMAIL PROTECTED]> writes: > Greg Stark <[EMAIL PROTECTED]> writes: > > I'm not saying pgfoundry should be shut down. But trying to force > > projects out into the sterile landscape where they get little use and > > little support is a death warrant. And unnecessary. > > > I think what I would suggest is going through pgfoundry, and checking in the > > stable release of any good looking project into the contrib directory of the > > Postgres distribution. > > In other words, decide that pgfoundry is a dead end that will never > work, and so instead we'll load that maintenance effort back onto the > core developers. > > NO, THANK YOU. Er. No that's not what I'm saying at all. What I'm saying is that pgfoundry will eventually happen. It will eventually be the case that there are enough projects that people will look there when they need something instead of just assuming it doesn't exist. But you can't just snap your fingers and make it happen. If all you have is a couple dozen packages and you banish them to some place nobody knows about then all that will accomplish is killing them off. I don't really see the contrib directory taking up much "maintenance effort" in the recent past. Even major projects like GiST don't really mean Core has to take the main brunt of the maintenance. It just means that people have a chance of finding tsearch et al and the upstream maintainers. I'm mainly thinking about server modules like all of the contrib directories. I don't see any obvious way to integrate things like pgpool into the same model. > It's entirely likely that we haven't figured out how to make pgfoundry > work yet. But figure it out we must, or the project-as-a-whole will die > of its own weight. Not everything can be part of the core. Eventually. But that's not the case today. The existing contrib directory hasn't killed the project with its weight. And neither will adding half a dozen more files. Note that the existence of pgfoundry doesn't mean that the core distribution won't grow either. Perl has more packages in its core distribution than Postgres has including contrib and pgfoundry. Many of those packages are also on CPAN but are included in a base install. -- greg ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] inclusions WAS: Increased company involvement
Greg Stark <[EMAIL PROTECTED]> writes: > I'm not saying pgfoundry should be shut down. But trying to force > projects out into the sterile landscape where they get little use and > little support is a death warrant. And unnecessary. > I think what I would suggest is going through pgfoundry, and checking in the > stable release of any good looking project into the contrib directory of the > Postgres distribution. In other words, decide that pgfoundry is a dead end that will never work, and so instead we'll load that maintenance effort back onto the core developers. NO, THANK YOU. It's entirely likely that we haven't figured out how to make pgfoundry work yet. But figure it out we must, or the project-as-a-whole will die of its own weight. Not everything can be part of the core. This isn't directly applicable to the PLs, since those are large efforts (and thereby relatively few in number) and they tend to have very high-bandwidth linkages to the core server. But to treat everything as having those same needs is a recipe for failure. regards, tom lane ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] inclusions WAS: Increased company involvement
Josh Berkus writes: > 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. Well I think you inadvertently pointed out why the distinction between these projects and Postgres. You described them as "projects with lots of options". By comparison Postgres has a fairly small and manageable set of options. modules.apache.org lists 393 Apache modules. Perl has 7,976 modules on CPAN, and of course the number of applications for Linux isn't even worth counting. pgfoundry has 88 projects. All of these projects grew up gradually through a natural evolutionary process. At first lots of stuff was included in any of these. It's only when there are enough projects to make it worthwhile for anyone to look in these outside repositories like CPAN or modules.apache.org that they hit critical mass and become self-sustaining. I'm not saying pgfoundry should be shut down. But trying to force projects out into the sterile landscape where they get little use and little support is a death warrant. And unnecessary. I think what I would suggest is going through pgfoundry, and checking in the stable release of any good looking project into the contrib directory of the Postgres distribution. -- greg ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] inclusions WAS: Increased company involvement
On Tue, May 03, 2005 at 09:19:41PM -0700, Josh Berkus wrote: > I do find it kind of funny that we include the PLs but not the server-side > drivers, but that decision precedes my tenure on Core. Sorry, you lost me -- what are server-side drivers? -- Alvaro Herrera (<[EMAIL PROTECTED]>) "Postgres is bloatware by design: it was built to house PhD theses." (Joey Hellerstein, SIGMOD annual conference 2002) ---(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: > Errm.. UTF-16/32 Ah, I thought that was what you meant. Right now we have a *ton* of problems with supporting encodings that need embedded zero bytes, because there are APIs all over the place that use zero-terminated strings. I don't foresee that it will ever be worth the trouble to make such encodings work natively inside the backend. It might possibly be worth the trouble to allow 'em as client encodings ... but that would require fixing not just the encoding converters, but the FE/BE protocol, libpq, psql, pg_dump, and who knows what other client-side software. If we're willing to make a commitment to go down that long hard road, it'd make sense to define the encoding conversion API to support strings with embedded nulls. Personally I'm agin it --- I think that the needed development effort would be better spent elsewhere. But my personal needs don't stretch further than 7-bit ASCII so maybe I'm not the best guy to make such decisions. 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] inclusions WAS: Increased company involvement
Josh Berkus writes: > 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. I think quite a lot of the /contrib stuff is there on basically historical reasons --- ie, it got in before we had gborg or pgfoundry as alternatives, and no one has felt it worthwhile to crusade to remove it. (You can't just "remove it" without at least setting up a working pgfoundry version, so this isn't a zero-effort thing ... whereas leaving it where it is is close to zero effort ...) I'd not want to see contrib slimmed down to nothing, because it has good use as a testbed for problems with our infrastructure for building external modules. But a few samples of each basic type of add-on would be enough for that, I think. 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] inclusions WAS: Increased company involvement
Dave, > My main concern was pushing out existing code, not adding code that was > not in the tarball. > I would have to agree deciding which to include would be onerous. I personally am not proposing pushing stuff out, except some of the legacy (i.e. not maintained) contrib modules. I do find it kind of funny that we include the PLs but not the server-side drivers, but that decision precedes my tenure on Core. -- Josh Berkus Aglio Database Solutions San Francisco ---(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] inclusions WAS: Increased company involvement
Josh Berkus wrote: 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. My main concern was pushing out existing code, not adding code that was not in the tarball. I would have to agree deciding which to include would be onerous. 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. This has never been an issue before, AFAIK, nobody with commit privliges in a separate package has ever changed the code where they weren't supposed to. To sum this up; the arguments presented are: 1) The tarball is/was too big however nobody ever complained. 2) CVS does not allow different groups to have commit privliges, but nobody has ever violated the trust Is this really the situation ? >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. -- Dave Cramer http://www.postgresintl.com 519 939 0336 ICQ#14675561
Re: [HACKERS] inclusions WAS: Increased company involvement
Andrew, > 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. Sorry, that came off kinda harsh.Seriously, I personally would love to see a proposal of a coherent system of what should and should not get included. -- 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] A proper fix for the conversion-function problem
Errm.. UTF-16/32 > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of John Hansen > Sent: Wednesday, May 04, 2005 1:22 PM > To: Tom Lane; Tatsuo Ishii > Cc: pgsql-hackers@postgresql.org > Subject: 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 > > ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] pg_locks needs a facelift
On Tue, May 03, 2005 at 11:43:41PM -0400, Tom Lane wrote: > "Jim C. Nasby" <[EMAIL PROTECTED]> writes: > > I wish you wouldn't since http://rrs.decibel.org uses it. > > Don't worry, I'll veto any immediate removal of functionality ;-) Yes, but will core (or worse, that Bruce guy) over-ride your veto? ;P > 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. Hopefully by then I'll have come up with a reason not to support pre-8.whenever_userlock_is_improved. :) -- 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 6: Have you searched our list archives? http://archives.postgresql.org
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
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] 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] 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] 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] 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
> 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] [PERFORM] Bad n_distinct estimation; hacks suggested?
Quoting Josh Berkus : > 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
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] 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] 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] 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] 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] [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] 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: [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-.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: [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: [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: [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
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: 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] [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] [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] 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] 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
> -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] 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
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])
[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: [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
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
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
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: [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
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: [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
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: [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
* 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?
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
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: [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
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, 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
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: [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: [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: [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?
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
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
[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
* 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
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 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
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
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: [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 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: [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
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: [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] 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: [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] 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
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, 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: [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: [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
[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: [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
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: [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: [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] 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
[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: [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]
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: [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
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] 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: [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
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] 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: [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] 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] 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: [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
