[HACKERS] Really odd corruption problem: cannot open pg_aggregate: No such file or directory
So, one of the many machines that I support seems to have developed an incredibly odd and specific corruption that I've never seen before. Whenever a query requiring an aggregate is attempted, it spits out: cannot open pg_aggregate: No such file or directory and fails. If I do: select * from pg_class where relname='pg_aggregate'; I see that the relation exists. If I check the relfilenode in the data directory, that exists, and seems to be an object file containing what should be the basic aggregate functions. version: PostgreSQL 7.2.3 on i686-pc-linux-gnu, compiled by GCC gcc (GCC) 3.2 20020903 (Red Hat Linux 8.0 3.2-7) The system ran for a few weeks before anything odd happened, and then suddenly this. Does anyone have any ideas? Now that I look at the above string, I realize that the system /is/ an Athlon processor. Does anyone know if there could be an issue between the i686 and athlon optimizations? -- Adam Haberlach | When your product is stolen by thieves, you [EMAIL PROTECTED] | have a police problem. When it is stolen by http://mediariffic.com | millions of honest customers, you have a | marketing problem. - George Gilder ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Really odd corruption problem: cannot open pg_aggregate: No such file or directory
On Thu, Jul 24, 2003 at 10:17:06AM -0700, Adam Haberlach wrote: So, one of the many machines that I support seems to have developed an incredibly odd and specific corruption that I've never seen before. Whenever a query requiring an aggregate is attempted, it spits out: cannot open pg_aggregate: No such file or directory and fails. If I do: select * from pg_class where relname='pg_aggregate'; I see that the relation exists. If I check the relfilenode in the data directory, that exists, and seems to be an object file containing what should be the basic aggregate functions. version: PostgreSQL 7.2.3 on i686-pc-linux-gnu, compiled by GCC gcc (GCC) 3.2 20020903 (Red Hat Linux 8.0 3.2-7) The system ran for a few weeks before anything odd happened, and then suddenly this. Does anyone have any ideas? Now that I look at the above string, I realize that the system /is/ an Athlon processor. Does anyone know if there could be an issue between the i686 and I'd like to thank everyone for the quick responses and the suggestion to strace the postmaster. open(/var/lib/pgsql/data/base/16556/16406, O_RDWR) = -1 ENOENT (No such file or directory) It looks like a file /was/ missing, and I had been looking in the wrong place to verify that it was there (the template database). I'm going to chalk this one up to bad hardware and hope it doesn't happen again. Thanks again... -- Adam Haberlach | When your product is stolen by thieves, you [EMAIL PROTECTED] | have a police problem. When it is stolen by http://mediariffic.com | millions of honest customers, you have a | marketing problem. - George Gilder ---(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] Manual fixing of plpgsql_call_handler binary location
On Sat, Jun 28, 2003 at 01:25:12AM -0400, Tom Lane wrote: Christopher Kings-Lynne [EMAIL PROTECTED] writes: Will I destroy things if I execute update pg_proc set probin = '/usr/lib/pgsql/plpgsql.so' where proname = 'plpgsql_call_handler'; Nope ... that's what I'd probably do. Even better change it to '$libdir/plpgsql.so'. Good point. In fact the really preferred spelling (which you'd get from a fresh 'createlang' run) is just '$libdir/plpgsql'. Both the path and the shlib extension are better left to the backend to supply than to hardwire in. I'm possibly more aware of this than most folk, since I like to use HPUX which spells the shlib extension .sl ... Awesome -- I've questioned to myself the wisdom of having this sort of thing hardcoded, but it looks like it's already been solved. Thanks, all... -- Adam Haberlach | When your product is stolen by thieves, you [EMAIL PROTECTED] | have a police problem. When it is stolen by http://mediariffic.com | millions of honest customers, you have a | marketing problem. - George Gilder ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
[HACKERS] Manual fixing of plpgsql_call_handler binary location -- good idea?
I know that we're all in end-of-release hurry, but I've got a quick question. We've got some machines that had postgres installed in /usr/local/pgsql and we are moving their data directories, wholesale, onto machines with postgres in the standard RedHat locations. This works just fine except for the hardcoded-ness of the plpgsql_call_handler having been previously set to /usr/local/pgsql/lib/plpgsql.so Will I destroy things if I execute update pg_proc set probin = '/usr/lib/pgsql/plpgsql.so' where proname = 'plpgsql_call_handler'; On the machines? This seems to work, but I wanted to see if anyone out there wanted to tell me about this being a really stupid idea. -- Adam Haberlach | When your product is stolen by thieves, you [EMAIL PROTECTED] | have a police problem. When it is stolen by http://mediariffic.com | millions of honest customers, you have a | marketing problem. - George Gilder ---(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] location of the configuration files
On Thu, Feb 13, 2003 at 05:59:17PM -0500, Robert Treat wrote:
On Thu, 2003-02-13 at 15:08, mlw wrote:
Stephan Szabo wrote:
On Thu, 13 Feb 2003, mlw wrote:
I have absolutely no problem debating and augmenting the feature. None
what so ever, I am more pushing to get momentum to actually do it.
Stick with it, I think most of us here can see the value in the option,
but there are valid concerns that it be implemented correctly.
Personally I think a postgresql installation is much more like an apache
installation, which generally contains all of the files (data and
config) under /usr/local/apache. Maybe someone can dig more to see if
that system is more appropriate a comparison than something like bind.
I think you are making a pretty uninformed, if not just plain wrong
generalization. I've run exactly one system with apache configuration
files in /usr/local/apache, and even then, the data was not there.
A quick straw poll of the people I know who actually do run real systems
also mentioned that they use packaging systems like encap or rpm to manage
upgrades, and would almost never put datafiles into /usr/local.
RedHat (7.3 at least)'s default httpd datafiles go in /var/www/html and
config goes in /etc/httpd
One OpenBSD user I talked to puts his in /home/www and config files in
/etc/httpd. The defaults are /var/www and /var/www/conf
Another user reports:
On systems that I set up I have /web/{apache|httpd}/ and put all
the config info there.
And /web/sites/name/ holds site data.
What does this mean?
People will put things in different places, and there are typically
very good reasons for this. This is ESPECIALLY true when one wants to
have configuration files, at least the base ones in a common place such
as /etc or /usr/local/etc in order to make backup of configuration easy
and clean, while leaving data somewhere else for performance or magnitude
of partition reasons. It just makes sense to ME to have postgresql.conf
reside in /etc, yet put my data in /var/data/postgresql, yet retain the
option to put my data in /raid/data/postgresql at a later date, when the
new hardware comes in.
Yes, symlinks are an option on most systems. No, they are not a good
one on most systems.
What _I_ would like to see:
o. a default postgresql.conf location of $PREFIX/data/postgresql.conf
o. a default PGDATA location of whatever directory postgresql.conf is in
(this should maintain backward compatibility)
o. a ./configure - time option to override the location of the postgresql.conf
o. a run-time option to override the location of the postgresql.conf
o. options in postgresql.conf to specify the location of PGDATA and PID files.
($PREFIX is already settable at ./configure - time)
This would allow:
o. Config files in /usr/local/pgsql/data, /etc, /usr/local/etc, ~postgresql,
or /dev/.hidden-node, whichever you prefer, so long as you either know
the compile-time default, or are willing to specify it at startup.
o. Datafiles to be in /usr/local/pgsql/data, /var/data, /raid0, /nfs/bigmount
or whichever you prefer, so long as you either know the compile-time default,
or are willing to specify it in a config file that you specify at startup.
Does it add complexity to the system? Sure -- a very little bit, IMHO, especially
compared to the BTREE-folding that I see being bantered about.
Is it some work? Sure -- a very little bit, and it seems that it has already
been done.
However, this seems, to me, to be a very small addition that has some real-world
(and yes, we need to start paying attention to the real world) advantages.
And finally, don't go telling me that I'm wrong to put my data and config files
where I am. You can offer advice, but I'm probably going to ignore it because
I like where they are and don't need to explain why.
--
Adam Haberlach | Because manholes are round.
[EMAIL PROTECTED] |
http://mediariffic.com |
---(end of broadcast)---
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly
Re: [HACKERS] Win32 port powerfail testing
On Sat, Feb 01, 2003 at 11:30:17AM -0600, Greg Copeland wrote: On Sat, 2003-02-01 at 00:34, Adam Haberlach wrote: On Sat, Feb 01, 2003 at 12:27:31AM -0600, Greg Copeland wrote: On Fri, 2003-01-31 at 14:36, Dave Page wrote: Please go with XFS or ext3. There are a number of blessed and horror stories which still float around about reiserfs (recent and old; even though I've never lost data with it -- using it now even). Might be worth testing FAT32 on NT as well. Even if we don't advocate it's use, it may not hurt to at least get an understanding of what one might reasonably expect from it. I'm betting there are people just waiting to run with FAT32 in the Win32 world. ;) You'd better go with NTFS. There are a number of blessed and horror stories which still float around about FAT32 (recent and old; even though I've never lost data with it -- using it now even now. Might be worth testing reiserfs on Linux as well. Even if we don't advocate it's use, it may not hurt to at least get an understanding of what one my reasonably expect from it. I'm better there are people just waiting to run with reiserfs in the Linux world. ;) Regards, and tongue firmly in cheek, Touche! :P While I understand and even appreciate the humor value, I do believe the picture is slightly different than your analysis. If we make something that runs on Win32 platforms, might it also run on Win98, WinME, etc.? Let's face the facts that should it also run on these platforms, it's probably only a matter of time before someone has it running on FAT32 (even possible on NT, etc). In other words, I'm fully expecting the lowest common denominator of MySQL user to be looking at PostgreSQL on Win32. Which potentially means lots of FAT32 use. And yes, even for a production environment. Ack! Double-ack! I was just trying to point out the inherent elitist bias in saying that Microsoft's old filesystem should be tested, even though it's use is discouraged, while one of Linux's new filesystems shouldn't, even though it's use is popular. There's a huge double standard here, caused by fear, uncertainty, and doubt. I'm just personally pretty tired of this anti-Microsoft bias. I'm going to be frank and say that many of the people here sound like a bunch of elitist assholes who refuse to sully themselves with a well-used, well-supported, and lately very useful operating system. For those of you who know my history (or care), I've supported Solaris, Linux, Win NT from 3.51 on up, and worked at one of the non-Linux anti-Microsoft companies for 4 years. I worked in a testlab where we tested and broke NT (usually caused by driver failures), SCO Unix (who KNOWs what made it panic), and Netware (effectively bulletproof). The fact is, the Win32 platform is mature. It is a modern operating system, and just because they don't do some things the way that the old guard Unix greybeards to doesn't necessarily make it inferior. What's more, all of this testing of filesystems is pretty moot at some point. So far, I've lost more data and time due to a bad locking procedure during vacuums (forcing a lot of quiet in-field upgrades from 7.2.2 to 7.2.3) then I ever expect to lose due to power failure. If we could spend a little more time testing the actual product and a little less time worrying about the underlying operating system, I'd be pretty happy. ...and I'm done discussing the issue for now, since there's not much more for me to say... -- Adam Haberlach | If I have hacked deeper than them, it is [EMAIL PROTECTED] | because I stand in their trenches. http://mediariffic.com |-- Graham Nelson ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
[HACKERS] My only post with regard to query caching
After reading way too many threads on this (probably too many on pgsql-* in general) I'll just go over how I feel about the caching issue. It seems that MySQL has implemented a system that allows the database to cache queries that are frequently used and reduce latency for them. This, to me, seems like a very nice low-hanging fruit optimization, especially for web systems. === Examples Search Pages: I implented a bug database. The main entry point was a Define your search page which presented quite a few options. Many of them were drop-down lists. This page did five or six queries to do things like find the list of engineers in the company, categories for bugs, and versions of software. The results of those queries probably changed once per month, but were done several times/day. While they are simple and may not have cost much, I can see how a simple cache would make them cost less. Home Pages: Frequently, in the 'blog case (such as my home page), a lookup is done every time the page is hit. I update that table every couple of days, but it is accessed much more often. Once again, this is a fairly common usage pattern in the web environment that /may/ be a good candiate for this sort of caching. These are two frequently-used design patterns which I think would benefit from this optimization. MySQL, and some of their customers seem to think so, too. === Common Arguments This shouldn't be in the database! Arguably, yes. This is something that might be better handled by the application server. The app server may or may not have a unified connection pool to the database and can better organize the queries and caching. On the other hand, for the case of a database that is not on the same machine as the webserver, this is a good chance to reduce bandwidth. This is going to make things ugly/hard to implement/etc... Personally, I feel that too many of PostgreSQL's potential features get rejected out-of-hand on the grounds that implementation will be difficult or that it will make things gross (as though parts of PostgreSQL aren't gross already). While I've not looked /too/ closely, it seems that if one were to create a way for the system to maintain the results of a query, keyed by the text of the query itself, it would be easy for something in the query sequence to check and see if the query has already been done, and access it. We already hold resultsets between queries in order to handle cursors, so most of the framework must already be in there. Just keep each 'cacheable' query. NOTE: This probably implies that in the simple case, the cache cannot be used between different connections. The other issue is the expiration of the cache entries. Once again, for the Home Pages case above, I would be perfectly satisified if the cache was entirely blown away every time any UPDATE query was executed. This would handle most cases, except for triggers on non-UPDATE queries. Otherwise, we would need to less simple-case the issue by tracking when tables are actually updated, and for even more bonus points, track which tables affect which cache entries. === Editorial: PostgreSQL seems to spend a lot of time stressing ACID, and I believe this is a very good thing. I simply don't trust MySQL any more then I trust any other SQL interface to a flat datafile. Also, PostgreSQL has some very handy features involving datatypes, triggers, and stored procedures. But you all know that. MySQL is doing some things right. They are providing useful documentation. They are adding features that target the web market (they may be adding them incorrectly, however). If we expect PostgreSQL to beat MySQL in anything but My database is transactionally secure and We have a GECO optimizer pissing wars, we'll need to start becoming a little more competitive in the raw speed arena. I feel that this optimization, while it may not be trivial, is fairly low-hanging fruit that can help. I may even try to implement it, but I make no guarantees. -- Adam Haberlach | Who buys an eight-processor machine and then [EMAIL PROTECTED]| watches 30 movies on it all at the same time? http://newsnipple.com | Beats me. They told us they could sell it, so | we made it. -- George Hoffman, Be Engineer ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] Parser abort ignoring following commands
On Sat, May 26, 2001 at 05:57:16PM +0200, Peter Eisentraut wrote: Tom Lane writes: Peter Eisentraut [EMAIL PROTECTED] writes: No, I think there is another problem. How about something without selects: $ psql -c 'delete from pk; delete from xx;' ERROR: Relation 'xx' does not exist pk exists, but nothing is deleted. Sure, because the transaction is rolled back. The whole string is executed in one transaction. You will definitely break existing applications if you change that. Applications that rely on this behaviour are broken. It was always said that statements are in their own transaction block unless in an explicit BEGIN/COMMIT block. A statement is defined to end at the semicolon, not at the end of the string you submit to PQexec(). You put semicolons at the end of your strings to PQexec()? -- Adam Haberlach| At either end of the social spectrum there lies [EMAIL PROTECTED] | a leisure class. -- Eric Beck 1965 http://www.newsnipple.com | '88 EX500'00 ^ | http://youlook.org ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
[HACKERS] pg_atoi() behavior change? Intentional?
I've just upgraded to the beta4 in order to fix an RI deadlock we seemed to be having with 7.0.3 -- and it seems that one of the engineers has been writing some queries that cast a text field to an int and take advantage of the fact that we used to turn text fields with no digits into 0, much as C's atoi function works. The new behavior is to throw a parse error, which causes all kinds of problem. Is this intentional? I dimly remember seeing a whole lot of atoi discussion, but I can't seem to find it in my last two files of this mailing list. -- Adam Haberlach| All your base are belong to us. [EMAIL PROTECTED] | http://www.newsnipple.com | '88 EX500'00 ^ |
[HACKERS] Something smells in this schema...
I had postgres start blocking all it's UPDATEs on a production
database today, when an engineer added the following two tables,
among other things. We've had to restore from backup, and the
interesting thing is that when we re-add these tables, things
break again.
Version: PostgreSQL 7.0.2 on i686-pc-linux-gnu, compiled by gcc 2.95.2
(we were planning on going to beta4 in another week, and have done
some testing. This problem doesn't seem to occur on the engineer's
machine, which is already at beta4)
My first thought was the index on the boolean field in the time_cards,
which I could have sworn has caused me problems before. Anyone else see
anything wrong?
-- time_tasks.schema
create table time_tasks (
name char(2) primary key,
title text,
description text
);
insert into time_tasks (name, title) values ('CO', 'Communication');
insert into time_tasks (name, title) values ('DB', 'Debug');
.
.
.
-- time_cards.schema
create table time_cards (
id serial,
open bool not null default 't',
accounted bool not null default 'f',
uid int4 not null,
task char(2) not null,
project int4,
component text,
time_start int4,
time_stop int4,
total_minutes int4,
notes text
);
create index time_cards_open_pkey on time_cards (open);
create index time_cards_uid_pkey on time_cards (uid);
--
Adam Haberlach|A cat spends her life conflicted between a
[EMAIL PROTECTED] |deep, passionate, and profound desire for
http://www.newsnipple.com |fish and an equally deep, passionate, and
'88 EX500'00 ^ |profound desire to avoid getting wet.
Re: [HACKERS] Something smells in this schema...
On Fri, Feb 16, 2001 at 01:02:24PM -0500, Tom Lane wrote: Adam Haberlach [EMAIL PROTECTED] writes: I had postgres start blocking all it's UPDATEs on a production database today, when an engineer added the following two tables, among other things. We've had to restore from backup, and the interesting thing is that when we re-add these tables, things break again. "blocking"? Please define symptoms more precisely. The postgres process stalls. According to ps, it's it is attempting an UPDATE. I think it times out eventually (I was in disaster-recovery mode this morning, and not always waiting around for these things. :) My first thought was the index on the boolean field in the time_cards, which I could have sworn has caused me problems before. Anyone else see anything wrong? Pre-7.1 versions do have problems with large numbers of equal keys in a btree index, which is more or less the definition of an index on boolean. I'm dubious that such an index is of any value anyway ... Ok--I'll check this. Thanks for the incredibly fast response--my favorite thing about PostgreSQL is the fact that I can post to a mailing list and get clued answers from real developers, usually within hours if not minutes. -- Adam Haberlach|A cat spends her life conflicted between a [EMAIL PROTECTED] |deep, passionate, and profound desire for http://www.newsnipple.com |fish and an equally deep, passionate, and '88 EX500'00 ^ |profound desire to avoid getting wet.
[HACKERS] Sluggish inserts/updates ?
I've got a system in which a row is being created by one process, a notify is sent, and another process finds and then deletes the row. This whole interchange seems to be taking about a second, which seems oddly slow. As far as I know, I have the fsync-on-anything turned off (*). I'm mainly wondering if I should index/not index the key of the table, and if I should blame the hardware or Postgres? The hard drive on the RD server is pretty slow, although the CPU is pretty dang fast. I could also blame the notification system but that shouldn't be a problem, right? * Is there a good way to find out if this option is on/off? -- Adam Haberlach|A cat spends her life conflicted between a [EMAIL PROTECTED] |deep, passionate, and profound desire for http://www.newsnipple.com |fish and an equally deep, passionate, and '88 EX500'00 ^ |profound desire to avoid getting wet.
Re: [INTERFACES] Re: [HACKERS] PHP and PostgreSQL
On Mon, Jan 22, 2001 at 11:55:56PM -0500, Bruce Momjian wrote: On Wed, Dec 27, 2000 at 12:56:26AM -0500, Bruce Momjian wrote: I have been asked by the major PHP developer Rasmus Lerdorf to see if the PostgreSQL/PHP interface needs any improvements. Is the current PostgreSQL interface module in PHP adequate? Does it support all the current libpq features? If not, would someone submit some patches to the PHP folks. They want us to work well with PHP. They are basically encouraging us to improve it in any way we can. I use PHP and Postgres together quite a bit, and find the APIs complete enough for most things. However, just last week I implemented pg_lolseek($loid, $offset $whence) and pg_lotell($loid) For some stuff that we are working on. They are pretty straightforward, and I can package them up and submit them if someone wants. Would to send this over to the PHP folks for inclusion? Thanks. I sent them patches against the at-the-time up-to-date CVS tree back when this first came up, they said that they failed, so I sent them another set, and have not heard back from them. It doesn't seem to show up in the cvs logs. I'll bug someone again and see if I can find out what happened. I mean, they only have 240 people with write access to the cvs tree... -- Adam Haberlach|A cat spends her life conflicted between a [EMAIL PROTECTED] |deep, passionate, and profound desire for http://www.newsnipple.com |fish and an equally deep, passionate, and '88 EX500 |profound desire to avoid getting wet.
Re: [HACKERS] Lock on arbitrary string feature
On Thu, Jan 11, 2001 at 03:43:39PM +0800, Lincoln Yeoh wrote: Hi, Has anyone any input to offer on adding an arbitrary locking feature? Where GETLOCK "string" will lock on "string", the lock being only released at the end of a transaction. While the lock is held, other processes trying to do GETLOCK "string" will block until the lock is released. This feature can allow applications to better serialize things. For example: inserting unique records. Cooperating applications could just do something like: GETLOCK "mytable.key2=1234"; SELECT count(*) from mytable where key2=1234 for update; if count==0, insert the stuff. elsif count==1 update the stuff instead else something is wrong! The lock will thus only affect applications interested in mytable where key2=1234 We do something like this with listen/notify pairs. To syncronize two clients, we have them each listen for the other's token string, send a notify, and then block on select(), checking for incoming notifications. When they get the notification, they send a notify back to the other side to un-block it. If anything, it would be nice if there were a way to make a LISTEN block the connection on a specific event tag, which is essentially what we are doing in our interface library. -- Adam Haberlach|A cat spends her life conflicted between a [EMAIL PROTECTED] |deep, passionate, and profound desire for http://www.newsnipple.com |fish and an equally deep, passionate, and '88 EX500 |profound desire to avoid getting wet.
Re: [HACKERS] GNU readline and BSD license
On Fri, Dec 29, 2000 at 07:15:05PM -0500, Tom Lane wrote: Alfred Perlstein [EMAIL PROTECTED] writes: Rasmus Lerdorf warned one of you guys that simply linking to GNU readline can contaminate code with the GPL. Readline isn't LGPL which permits linking without lincense issues, it is GPL which means that if you link to it, you must be GPL as well. I do not believe that. In fact, I'll go further and say "Horsepucky!" The GPL applies to works that "contain or are derived from" a GPL'd program. Linking to a separately distributed library does not cause psql either to contain or to be derived from libreadline. RMS already made a big stink about this, claiming that BeOS's use of an emulation layer to link to some GPL'ed network drivers was enough to force the GPL'ing of the kernel. Be backed down (and re-licensed the code from the source, IIRC). Sun recently released a "driver porting kit" that allowed similar drivers to be used in Solaris. There was some outcry on Slashdot, but I'm not sure how it ended up. I wouldn't mind having someone tell RMS to fuck off, though. -- Adam Haberlach|A cat spends her life conflicted between a [EMAIL PROTECTED] |deep, passionate, and profound desire for http://www.newsnipple.com |fish and an equally deep, passionate, and '88 EX500 |profound desire to avoid getting wet.
Re: [HACKERS] GNU readline and BSD license
On Fri, Dec 29, 2000 at 08:46:40PM -0500, Tom Lane wrote: Adam Haberlach [EMAIL PROTECTED] writes: RMS already made a big stink about this, claiming that BeOS's use of an emulation layer to link to some GPL'ed network drivers was enough to force the GPL'ing of the kernel. Did BeOS make distributions that included the GPL'd code? Yes. IIRC (this happened about the time I got here more then two years ago), Be released binary versions of the drivers with the standard distribution as well as source to them as sample code. RMS's main claim was that although the GPL'ed source was released as source, it had to link to the kernel to be useful, and therefore could not be distributed without source to the kernel. Was the GPL'd code essential for useful use of their system? No. -- Adam Haberlach|A cat spends her life conflicted between a [EMAIL PROTECTED] |deep, passionate, and profound desire for http://www.newsnipple.com |fish and an equally deep, passionate, and '88 EX500 |profound desire to avoid getting wet.
Re: [HACKERS] PHP and PostgreSQL
On Wed, Dec 27, 2000 at 12:56:26AM -0500, Bruce Momjian wrote: I have been asked by the major PHP developer Rasmus Lerdorf to see if the PostgreSQL/PHP interface needs any improvements. Is the current PostgreSQL interface module in PHP adequate? Does it support all the current libpq features? If not, would someone submit some patches to the PHP folks. They want us to work well with PHP. They are basically encouraging us to improve it in any way we can. I use PHP and Postgres together quite a bit, and find the APIs complete enough for most things. However, just last week I implemented pg_lolseek($loid, $offset $whence) and pg_lotell($loid) For some stuff that we are working on. They are pretty straightforward, and I can package them up and submit them if someone wants. -- Adam Haberlach|A cat spends her life conflicted between a [EMAIL PROTECTED] |deep, passionate, and profound desire for http://www.newsnipple.com |fish and an equally deep, passionate, and '88 EX500 |profound desire to avoid getting wet.
Re: [HACKERS] Using Threads?
On Mon, Dec 04, 2000 at 02:28:10PM -0600, Bruce Guenter wrote: On Mon, Nov 27, 2000 at 11:42:24PM -0600, Junfeng Zhang wrote: I am new to postgreSQL. When I read the documents, I find out the Postmaster daemon actual spawns a new backend server process to serve a new client request. Why not use threads instead? Is that just for a historical reason, or some performance/implementation concern? Once all the questions regarding "why not" have been answered, it would be good to also ask "why use threads?" Do they simplify the code? Do they offer significant performance or efficiency gains? What do they give, other than being buzzword compliant? Typically (on a well-written OS, at least), the spawning of a thread is much cheaper then the creation of a new process (via fork()). Also, since everything in a group of threads (I'll call 'em a team) shares the same address space, there can be some memory overhead savings. -- Adam Haberlach |"California's the big burrito, Texas is the big [EMAIL PROTECTED] | taco ... and following that theme, Florida is http://www.newsnipple.com| the big tamale ... and the only tamale that '88 EX500| counts any more." -- Dan Rather
Re: [HACKERS] beta testing version
On Sat, Dec 02, 2000 at 03:51:15PM -0600, Ross J. Reedstrom wrote: On Sat, Dec 02, 2000 at 11:31:37AM -0800, Don Baccus wrote: At 05:42 PM 12/2/00 +0100, Peter Eisentraut wrote: Don Baccus writes: Exactly what is PostgreSQL, Inc doing in this area? Good question... See http://www.erserver.com/. snip Boy, I can just imagine the uproar this statement will cause on Slashdot when the world finds out about it. That one doesn't worry me us much as this quote from the press release at http://www.pgsql.com/press/PR_5.html "We expect to have the source code tested and ready to contribute to the open source community before the middle of October. Until that time we are considering requests from a number of development companies and venture capital groups to join us in this process." Where's the damn core code? I've seen a number of examples already of people asking about remote access/replication function, with an eye toward implementing it, and being told "PostgreSQL, Inc. is working on that". It's almost Microsoftesque: preannounce future functionality suppressing the competition. For What It's Worth: In the three years (has it really been that long?) that I've been off and on Postgres mailing lists, I've probably seen at least 100 requests for replication, with about 40 of them mentioning implementing it themself. I'm pretty sure that being told "PostgreSQL Inc. is working on that" is not the only thing stopping it from happening. Most people just aren't up to making it happen. -- Adam Haberlach |"California's the big burrito, Texas is the big [EMAIL PROTECTED] | taco ... and following that theme, Florida is http://www.newsnipple.com| the big tamale ... and the only tamale that '88 EX500| counts any more." -- Dan Rather
Re: [HACKERS] beta testing version
On Sat, Dec 02, 2000 at 07:32:14PM -0800, Don Baccus wrote: At 02:58 AM 12/3/00 +, Thomas Lockhart wrote: PostgreSQL, Inc perhaps has that as a game plan. I'm not so much concerned about exactly what PG, Inc is planning to offer as a proprietary piece - I'm purist enough that I worry about what this . . . As soon as you find a business model which does not require income, let me know. Red herring, and you know it. The question isn't whether or not your business generates income, but how it generates income. So far, Open Source doesn't. The VA Linux IPO made ME some income, but I'm not sure that was part of their plan... Your comment is the classic one tossed out by closed-source, proprietary software advocates who dismiss open source software out-of-hand. Couldn't you think of something better, at least? Like ... something original? The .com'ers are trying it at the moment, and there seems to be a few flaws... ;) That's a horrible analogy, and I suspect you know it, but at least it is original. It wasn't an analogy. In any case, can we create pgsql-politics so we don't have to go over this issue every three months? Can we create pgsql-benchmarks while we are at it, to take care of the other thread that keeps popping up? -- Adam Haberlach |"California's the big burrito, Texas is the big [EMAIL PROTECTED] | taco ... and following that theme, Florida is http://www.newsnipple.com| the big tamale ... and the only tamale that '88 EX500| counts any more." -- Dan Rather
Re: [HACKERS] Initdb not running on beos
On Mon, Nov 27, 2000 at 04:09:46PM -0500, Tom Lane wrote: Cyril VELTER [EMAIL PROTECTED] writes: Unfortunatly, there is no hard link on beos :=(. link and unlink are there, but link always return "No such file or directory". Somewhere right around here is where I am going to ask why we are entertaining the idea of a BeOS port in the first place... it's evidently not Unix or even trying hard to be close to Unix. You've asked this before. How does Windows manage to work? -- Adam Haberlach |"California's the big burrito, Texas is the big [EMAIL PROTECTED] | taco ... and following that theme, Florida is http://www.newsnipple.com| the big tamale ... and the only tamale that '88 EX500| counts any more." -- Dan Rather
