Re: [HACKERS] PQnotifies() in 7.3 broken?
Peter Eisentraut wrote: Tom Lane writes: It is not real clear to me whether we need a major version bump, rather than a minor one. We *do* need to signal binary incompatibility. Who can clarify the rules here? Strictly speaking, it's platform-dependent, but our shared library code plays a bit of abuse with it. What it comes down to is: If you change or remove an interface, increment the major version number. If you add an interface, increment the minor version number. If you did neither but changed the source code at all, increment the third version number, if we had one. My take on it is: if you break binary compatibility, which includes semantic dependencies, then you increment the major version number. Otherwise you increment the minor version number. Since the change we're talking about apparently broke binary compatibility, it calls for a major version number change. Protocol incompatibility requires a different method of enforcement altogether. Incrementing the major number of the library isn't going to do you any good for that (7.2 clients on remote systems won't have any idea that the libraries on the 7.3 server have changed that much). All MHO, of course... -- Kevin Brown [EMAIL PROTECTED] This is your .signature virus: begin 644 .signature (9V]T8VAA(0K0z end This is your .signature virus on drugs: Any questions? ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
[HACKERS] DB Tuning Notes for comment...
The notes below are the results of various tuning issues experienced
recently on a large database (several GB) that has many tables and a high
transient data flow (ie. thousands of records added, updated, and deleted
every hour) on a few tables. This kind of data flow is not at all well
handled by the default postgresql settings. Experiments have also been
conducted using a much smaller test database with a text field written to a
TOAST relation (which is what the large table contains).
I think this example is useful because it encapsulates in several hours the
level of updates that most of us see in several weeks, so the rules below
should apply equally well but in different time frames, with provisos as
noted. The database in question is subject to periodic bulk deletes where
up to 50% of the rows in the large table are deleted. It is also has to run
24x7.
Any comments or suggestions would be welcome.
Tuning
==
1. max_fsm_relations
First of all, the free space manager is useless at managing free space if
it can not map all relations (including system relations and toast
relations). The following query should give the correct ballpark:
select count(*) from pg_class where not relkind in ('i','v');
Set max_fsm_relations to a number greater than this. Add extra to deal with
any tables you will create etc. It costs 40 bytes per table, so be
generous - if it is set too low, you will get bizarre space usage.
[Note: the FSM is so bad at reclaiming space when this value is too low
that I believe it should be overridden at startup if it is not at least
equal to the result of the above query. Similarly, I think a warning should
be given at startup and/or runtime when it is exceeded, or work should be
done to make it dynamic - and it should then not be a config item].
2. VACUUM Frequency
---
Ideally VACUUM should run constantly; a future version will support
something like it. But for now, vacuum should be run when a significant
amount of data has been inserted, updated or deleted. The definition of
'significant' is not immediately obvious.
Most tables will *not* be updated frequently in most databases; such tables
can be vacuumed irregularly, or vacuumed when the more frequently updated
tables are vacuumed.
In our specific case we have one table that has a few rows ( 1000), but it
is updated as many as 3 times per second. In this case, we chose a 5 minute
interval, which results in at worst 1000 'dead' rows in the table as a
result of the updates. Since it was such a small table, we saw no reason to
vacuum every minute, or even constantly.
For larger or more complex tables, the output of VACUUM ANALYZE must be used.
The following is an extract of the output from a VACUUM VERBOSE of a simple
test database - the table is the TOAST table of a large text column, where
the table has been constructed to be 75% empty. The output is after
deleting some rows.
1 INFO: --Relation pg_toast.pg_toast_16979--
2 INFO: Index pg_toast_16979_index: Pages 575; Tuples 16384: Deleted 25984.
3 CPU 0.05s/0.16u sec elapsed 7.41 sec.
4 INFO: Removed 25984 tuples in 6496 pages.
5 CPU 0.75s/0.79u sec elapsed 14.17 sec.
6 INFO: Pages 22480: Changed 6496, Empty 0; Tup 16384: Vac 25984, Keep 0,
UnUsed 47552.
7 Total CPU 1.98s/1.05u sec elapsed 23.30 sec.
Line 6 shows that there are 22480 pages, and 6496 (roughly 25%) were
changed since the last vacuum. Line 4 indicates that these were all
removed. Note that when tuples are updated, a new copy of the record is
written and the old one deleted, so updates will also result in tuples
being 'removed'.
A more complex example follows; this was after deleting 512 rows and adding
256:
1 INFO: --Relation pg_toast.pg_toast_16979--
2 INFO: Index pg_toast_16979_index: Pages 667; Tuples 24576: Deleted 16384.
3 CPU 0.02s/0.10u sec elapsed 4.73 sec.
4 INFO: Removed 16384 tuples in 4096 pages.
5 CPU 0.52s/0.48u sec elapsed 9.38 sec.
6 INFO: Pages 20528: Changed 6144, Empty 0; Tup 24576: Vac 16384, Keep 0,
UnUsed 41152.
7 Total CPU 1.81s/0.64u sec elapsed 22.51 sec.
note that line 6 has a 'changed' value, and line 4 has a 'removed' value.
This gives some indication of the pages consumed and released in any period.
The final example is for 512 inserts, 512 updates (of different records)
and 512 deletes.
1 INFO: --Relation pg_toast.pg_toast_16979--
2 INFO: Index pg_toast_16979_index: Pages 854; Tuples 32768: Deleted 32768.
3 CPU 0.05s/0.20u sec elapsed 8.41 sec.
4 INFO: Removed 32768 tuples in 8192 pages.
5 CPU 1.01s/0.91u sec elapsed 13.52 sec.
6 INFO: Pages 26672: Changed 12288, Empty 0; Tup 32768: Vac 32768, Keep 0,
UnUsed 41152.
7 Total CPU 2.92s/1.25u sec elapsed 30.01 sec.
again it shows the effects of UPDATE/DELETE vs. INSERT.
In each case the 'Changed' value indicates the maximum number of pages
required between
Re: [HACKERS] [GENERAL] 7.3 txt2txtidx - crash
Yes i found this bug earlier.
There is a patch for it in the mail archives.
Magnus
Argo Priivits [EMAIL PROTECTED] wrote:
Hi,
I have a problem with contrib/tsearch module.
Simple select txt2txtidx('2-3') causes psql to crash with error:
server closed the connection unexpectedly
This probably means the server terminated abnormally
before or while processing the request.
As I found out, this happens allways when in txt2txtidx input
parameter occurs string with pattern: number hyphen or hyphen
number !!!
pg 7.3
redhat 7.3
Thanks, any idea ?
---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
(send unregister YourEmailAddressHere to [EMAIL PROTECTED])
[HACKERS] proposal: array utility functions phase 1
I'm working on the TODO item Allow easy display of usernames in a group in
the context of a slightly larger effort to improve usability of arrays. I'm
far enough down the road to have a better idea of where I want to go with
this, but I'd like to vet those ideas with the list so I don't waste too much
effort if everyone hates them ;-)
The first function borrows from an idea Nigel Andrews had -- i.e. expand an
array into rows (and possibly columns). It currently works like this:
-- 1D array
test=# select * from array_values('{101,102,103,104}'::int[]) as (a int, b1 int);
a | b1
---+-
1 | 101
2 | 102
3 | 103
4 | 104
(4 rows)
CREATE TABLE arr_text(f1 int, f2 text[]);
INSERT INTO arr_text VALUES (1, '{a,b,c}');
UPDATE arr_text SET f2[-2:0] = '{x,y,z}' WHERE f1 = 1;
CREATE OR REPLACE FUNCTION get_arr_text(int) RETURNS text[] AS 'SELECT f2 FROM
arr_text WHERE f1 = $1' LANGUAGE 'sql';
test=# select * from array_values(get_arr_text(1)) as (a int, b1 text);
a | b1
+
-2 | x
-1 | y
0 | z
1 | a
2 | b
3 | c
(6 rows)
-- 2D array
test=# select * from array_values('{{1,2,3,4},{5,6,7,8}}'::int[]) as (a int,
b1 int, b2 int, b3 int, b4 int);
a | b1 | b2 | b3 | b4
---++++
1 | 1 | 2 | 3 | 4
2 | 5 | 6 | 7 | 8
(2 rows)
It accepts type anyarray, and returns record. The first column preserves the
array subscript for the 1st dimension.
One question I have is this: what, if anything, should be done with 3 (and
higher) dimension arrays? I was considering returning 2 columns -- the 1st
dimension array subscript, and a 2nd column containing the sub-array left
over. E.g.:
array_values('{{{111,112},{121,122}},{{211,212},{221,222}}}'::int[]) would become:
a | b1
+---
1 | {{111,112},{121,122}}
2 | {{211,212},{221,222}}
Does this make sense, or is something else better, or would it be better not
to support 3 dim arrays and up?
Now on to the TODO item. Given the array_values() function, here's what I was
thinking of to implement listing members of a group:
CREATE OR REPLACE FUNCTION pg_get_grolist(text) RETURNS INT[] AS 'SELECT
grolist FROM pg_group WHERE groname = $1' LANGUAGE 'sql';
CREATE TYPE pg_grolist_rec AS (array_index int, member_name text);
CREATE OR REPLACE FUNCTION group_list(text) RETURNS SETOF pg_grolist_rec AS
'SELECT g.id, pg_get_userbyid(g.usesysid)::text AS member_name FROM
array_values(pg_get_grolist($1)) AS g(id int, usesysid int)' LANGUAGE 'sql';
test=# select * from pg_group;
groname | grosysid |grolist
-+--+---
g1 | 100 | {100,101}
g2 | 101 | {100,101,102}
(2 rows)
test=# select * from group_list('g2');
array_index | member_name
-+-
1 | user1
2 | user2
3 | user3
pg_get_grolist(text) is intended for internal use, as is the pg_grolist_rec
composite type. group_list() is intended as the user facing table function. I
would implement this by running the three statements above during initdb.
Any comments or objections WRT object names or the method of implementation? I
don't think this is a very speed critical application, but even using the sql
functions it is very fast:
test=# explain analyze select * from group_list('g2');
QUERY PLAN
Function Scan on group_list (cost=0.00..12.50 rows=1000 width=36) (actual
time=1.49..1.50 rows=3 loops=1)
Total runtime: 1.55 msec
(2 rows)
I have more planned beyond the above as outlined in an earlier post (see
http://archives.postgresql.org/pgsql-hackers/2002-11/msg01213.php).
Next on my list will be a split() function (as discussed in early September)
that creates an array from an input string by splitting on a given delimiter.
This is similar to functions in perl, php, and undoubtedly other languages. It
should work nicely in conjunction with array_values().
Sorry for the long mail and thanks for any feedback!
Joe
---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/users-lounge/docs/faq.html
[HACKERS] More on cursors in 7.3
Looking at my problem with changed cursor behaviour in 7.3 again, I noticed something interesting: a cursor in 7.3 apparently does not let you scroll back to its first row at all! Neither a move backward all or a move -n where n is equal to or greater than the cursor's current position, will let you fetch any more rows from the cursor. Scrolling back to the second row does work though. I can work around this in libpqxx, without too much trouble, but I'm not sure I should have to. Jeroen ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] [GENERAL] PostgreSQL Global Development Group
On Sun, 8 Dec 2002, Justin Clift wrote: Vince Vielhaber wrote: On Thu, 5 Dec 2002, Robert Treat wrote: Well, my previous employer uses postgresql, but they were under constant assault from their clients to use oracle or db2. Technically there was no reason to switch, but if your choice is switch databases or go out of business, there really isn't much choice. That tells me their clients wanted a commercial database, not one that's open source. All the marketing in the world won't change that. Really? Why do you say that? Because of this taken from the above quoted text: they were under constant assault from their clients to use oracle or db2 Last I looked neither Oracle or DB2 were open source, but they both just happen to be commercial and I don't see mysql mentioned. Anything else you don't understand about that? Vince. -- Fast, inexpensive internet service 56k and beyond! http://www.pop4.net/ http://www.meanstreamradio.com http://www.unknown-artists.com Internet radio: It's not file sharing, it's just radio. ---(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] [GENERAL] PostgreSQL Global Development Group
Vince Vielhaber wrote: Because of this taken from the above quoted text: they were under constant assault from their clients to use oracle or db2 Last I looked neither Oracle or DB2 were open source, but they both just happen to be commercial and I don't see mysql mentioned. And ? Regards and best wishes, Justin Clift Anything else you don't understand about that? Vince. -- My grandfather once told me that there are two kinds of people: those who work and those who take the credit. He told me to try to be in the first group; there was less competition there. - Indira Gandhi ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] More on cursors in 7.3
Jeroen T. Vermeulen [EMAIL PROTECTED] writes: Looking at my problem with changed cursor behaviour in 7.3 again, I noticed something interesting: a cursor in 7.3 apparently does not let you scroll back to its first row at all! Oh? regression=# begin; BEGIN regression=# declare c cursor for select * from int8_tbl; DECLARE CURSOR regression=# fetch all from c; q1|q2 --+--- 123 | 456 123 | 4567890123456789 4567890123456789 | 123 4567890123456789 | 4567890123456789 4567890123456789 | -4567890123456789 (5 rows) regression=# move backward all in c; MOVE 5 regression=# fetch all from c; q1|q2 --+--- 123 | 456 123 | 4567890123456789 4567890123456789 | 123 4567890123456789 | 4567890123456789 4567890123456789 | -4567890123456789 (5 rows) regression=# I believe it is true though that backing up a cursor only works for certain plan types (seqscan, indexscan, sort, maybe a couple others). That has always been true --- 7.3 is no better nor worse than prior releases. regards, tom lane ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] More on cursors in 7.3
On Sun, Dec 08, 2002 at 04:28:38PM -0500, Tom Lane wrote: I believe it is true though that backing up a cursor only works for certain plan types (seqscan, indexscan, sort, maybe a couple others). That has always been true --- 7.3 is no better nor worse than prior releases. Ah, I didn't know that. I guess the plan for select * from pg_tables must have changed in 7.3 then. Is any of this described in the docs somewhere? Jeroen ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] proposal: array utility functions phase 1
Joe Conway [EMAIL PROTECTED] writes:
[ much snipped ]
The first function borrows from an idea Nigel Andrews had -- i.e. expand an
array into rows (and possibly columns). It currently works like this:
-- 1D array
test=# select * from array_values('{101,102,103,104}'::int[]) as (a int, b1 int);
Now on to the TODO item. Given the array_values() function, here's what I was
thinking of to implement listing members of a group:
CREATE OR REPLACE FUNCTION pg_get_grolist(text) RETURNS INT[] AS 'SELECT
grolist FROM pg_group WHERE groname = $1' LANGUAGE 'sql';
CREATE TYPE pg_grolist_rec AS (array_index int, member_name text);
CREATE OR REPLACE FUNCTION group_list(text) RETURNS SETOF pg_grolist_rec AS
'SELECT g.id, pg_get_userbyid(g.usesysid)::text AS member_name FROM
array_values(pg_get_grolist($1)) AS g(id int, usesysid int)' LANGUAGE 'sql';
This crystallizes something that has been bothering me for awhile: the
table function syntax is severely hobbled (not to say crippled :-() by
the fact that the function arguments have to be constants. You really
don't want to have to invent intermediate functions every time you want
a slightly different query --- yet this technique seems to require *two*
bespoke functions for every query, one on each end of the array_values()
function.
The original Berkeley syntax, messy as it was, at least avoided this
problem. For example, I believe this same problem could be solved
(approximately) with
select array_values(grolist) from pg_group where groname = 'g2'
--- getting the users shown as names instead of numbers would take an
extra level of SELECT, but I leave the details to the reader.
I think we ought to try to find a way that table functions could be used
with inputs that are taken from tables. In a narrow sense you can do
this already, with a sub-SELECT:
select * from my_table_func((select x from ...));
but (a) the sub-select can only return a single value, and (b) you can't
get at any of the other columns in the row the sub-select is selecting.
For instance it won't help me much to do
select * from
array_values((select grolist from pg_group where groname = 'g2'))
if I want to show the group's grosysid as well.
I know I'm not explaining this very well (I'm only firing on one
cylinder today :-(), but basically I think we need to step back and take
another look at the mechanism before we start inventing tons of helper
functions to make up for the lack of adequate mechanism.
As for array_values() itself, it seems fairly inelegant to rely on the
user to get the input and output types to match up. Now that we have
an anyarray pseudotype, I think it wouldn't be unreasonable to hack up
some kluge in the parser to allow reference to the element type of such
an argument --- that is, you'd say something like
create function array_values(anyarray) returns setof anyarray_element
and the parser would automatically understand what return type to assign
to any particular use of array_values. (Since type resolution is done
bottom-up, I see no logical difficulty here, though the implementation
might be a bit of a wart...)
regards, tom lane
---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] [GENERAL] PostgreSQL Global Development Group
On Mon, 9 Dec 2002, Justin Clift wrote: Vince Vielhaber wrote: Because of this taken from the above quoted text: they were under constant assault from their clients to use oracle or db2 Last I looked neither Oracle or DB2 were open source, but they both just happen to be commercial and I don't see mysql mentioned. And ? And what? If you can't understand the above you're in the wrong business. Vince. -- Fast, inexpensive internet service 56k and beyond! http://www.pop4.net/ http://www.meanstreamradio.com http://www.unknown-artists.com Internet radio: It's not file sharing, it's just radio. ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] More on cursors in 7.3
Jeroen T. Vermeulen [EMAIL PROTECTED] writes: Ah, I didn't know that. I guess the plan for select * from pg_tables must have changed in 7.3 then. [looks...] Yeah, there's a join to pg_namespace in there now. Is any of this described in the docs somewhere? Fraid not. regards, tom lane ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] More on cursors in 7.3
On Sun, Dec 08, 2002 at 05:09:09PM -0500, Tom Lane wrote: Is any of this described in the docs somewhere? Fraid not. Damn blast. I was rather counting on cursors that could back up for my nifty CachedResult class (which acts more or less like a normal result set but transparently fetches rows on demand). Now if I understood a bit more of what's going on here, at least I could document it... Jeroen ---(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] [GENERAL] PostgreSQL Global Development Group
Vince Vielhaber wrote: On Mon, 9 Dec 2002, Justin Clift wrote: Vince Vielhaber wrote: Because of this taken from the above quoted text: they were under constant assault from their clients to use oracle or db2 Last I looked neither Oracle or DB2 were open source, but they both just happen to be commercial and I don't see mysql mentioned. And ? And what? If you can't understand the above you're in the wrong business. And ? Regards and best wishes, Justin Clift Vince. -- My grandfather once told me that there are two kinds of people: those who work and those who take the credit. He told me to try to be in the first group; there was less competition there. - Indira Gandhi ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] More on cursors in 7.3
Jeroen T. Vermeulen [EMAIL PROTECTED] writes: Now if I understood a bit more of what's going on here, at least I could document it... Well, you could dig through backend/executor/node*.c and see which of the node types pay attention to es_direction. To a first approximation it looks like these do: Functionscan Append Indexscan Mergejoin Limit Material Subqueryscan Seqscan Sort Tidscan although I have not thought about which other upper plan nodes might be okay (ie, they're safe if their input nodes are). Also, a Material or Sort node will hide any direction-unsafety in its input. regards, tom lane ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] [GENERAL] PostgreSQL Global Development Group
On Mon, 9 Dec 2002, Justin Clift wrote: Vince Vielhaber wrote: On Mon, 9 Dec 2002, Justin Clift wrote: Vince Vielhaber wrote: Because of this taken from the above quoted text: they were under constant assault from their clients to use oracle or db2 Last I looked neither Oracle or DB2 were open source, but they both just happen to be commercial and I don't see mysql mentioned. And ? And what? If you can't understand the above you're in the wrong business. And ? That's what I thought. You have no argument so your just typing. Vince. -- Fast, inexpensive internet service 56k and beyond! http://www.pop4.net/ http://www.meanstreamradio.com http://www.unknown-artists.com Internet radio: It's not file sharing, it's just radio. ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] More on cursors in 7.3
On Sun, Dec 08, 2002 at 05:28:22PM -0500, Tom Lane wrote: Well, you could dig through backend/executor/node*.c and see which of the node types pay attention to es_direction. To a first approximation it looks like these do: I'll be honest with you: I don't know much about the internals and this is pure Greek to me... And I never was much good at Greek in school. although I have not thought about which other upper plan nodes might be okay (ie, they're safe if their input nodes are). Also, a Material or Sort node will hide any direction-unsafety in its input. More Greek, I'm afraid. :-( Jeroen ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] [GENERAL] PostgreSQL Global Development Group
On 7 Dec 2002, Rod Taylor wrote: What too many people fail to realize is that in a commercial environment many companies want another company to point the finger at in case of disaster. Sybase failed, or HP failed, or IBM failed, or Microsoft failed. They feel they can do something about that. If they lose a few million they have someone they can go after, who are they going to go after if PostgreSQL fails them? Marc? Bruce? This is when you start to shout that RedHat offers commercial support, licencing, etc. INCLUDING a free, non-restrictive source licence to the core components of RHDB. I had considered mentioning redhat but didn't want to blur things. Red hat markets PostgreSQL under a different name and they're offering a complete package (including support as you note). The PGDG isn't doing that and they shouldn't be. Vince. -- Fast, inexpensive internet service 56k and beyond! http://www.pop4.net/ http://www.meanstreamradio.com http://www.unknown-artists.com Internet radio: It's not file sharing, it's just radio. ---(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] [GENERAL] PostgreSQL Global Development Group
On Sun, 2002-12-08 at 20:52, Vince Vielhaber wrote: Why do you say that? Because of this taken from the above quoted text: they were under constant assault from their clients to use oracle or db2 Last I looked neither Oracle or DB2 were open source, but they both just happen to be commercial and I don't see mysql mentioned. This is a reason to increase marketing effort. I know the word has pejorative overtones in our community, but it means talking about PostgreSQL so that the PHBs hear about it and therefore begin to feel comfortable about using it. If something is familiar, it feels safe. We need to make PostgreSQL familiar. That's why we need marketing. -- Oliver Elphick [EMAIL PROTECTED] LFIX Limited ---(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] [GENERAL] PostgreSQL Global Development Group
Vince Vielhaber wrote: That's what I thought. You have no argument so your just typing. Hi Vince, Was more hoping you'd care to share your basis for stating Robert's employers clients wanted a commercial database, after he mentioned specifically DB2 and Oracle. Knowing one of the obvious common factors they have and then stating it was definitely the reason - not having sought clarification nor confirmation from Robert - and then further stating that the PG Advocacy and Marketing group wouldn't be able to assist even if that were the case, is extremely bad form coming from anyone, let alone you. Please consider the statements you make by a more accurate approach in the future. Regards and best wishes, Justin Clift Vince. -- My grandfather once told me that there are two kinds of people: those who work and those who take the credit. He told me to try to be in the first group; there was less competition there. - Indira Gandhi ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] [GENERAL] PostgreSQL Global Development Group
On Mon, 9 Dec 2002, Justin Clift wrote: Vince Vielhaber wrote: That's what I thought. You have no argument so your just typing. Hi Vince, Was more hoping you'd care to share your basis for stating Robert's employers clients wanted a commercial database, after he mentioned specifically DB2 and Oracle. Knowing one of the obvious common factors they have and then stating it was definitely the reason - not having sought clarification nor confirmation from Robert - and then further stating that the PG Advocacy and Marketing group wouldn't be able to assist even if that were the case, is extremely bad form coming from anyone, let alone you. Then they come with the insults. Justin, I'm finished discussing this with you. You're obviously not capable of understanding it and you're simply wasting my time - like usual. Vince. -- Fast, inexpensive internet service 56k and beyond! http://www.pop4.net/ http://www.meanstreamradio.com http://www.unknown-artists.com Internet radio: It's not file sharing, it's just radio. ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] [GENERAL] PostgreSQL Global Development Group
On 8 Dec 2002, Oliver Elphick wrote: On Sun, 2002-12-08 at 20:52, Vince Vielhaber wrote: Why do you say that? Because of this taken from the above quoted text: they were under constant assault from their clients to use oracle or db2 Last I looked neither Oracle or DB2 were open source, but they both just happen to be commercial and I don't see mysql mentioned. This is a reason to increase marketing effort. I know the word has pejorative overtones in our community, but it means talking about PostgreSQL so that the PHBs hear about it and therefore begin to feel comfortable about using it. If something is familiar, it feels safe. We need to make PostgreSQL familiar. That's why we need marketing. Then why wasn't mysql in the list? It's familiar. Vince. -- Fast, inexpensive internet service 56k and beyond! http://www.pop4.net/ http://www.meanstreamradio.com http://www.unknown-artists.com Internet radio: It's not file sharing, it's just radio. ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] [GENERAL] PostgreSQL Global Development Group
On Sun, 2002-12-08 at 22:27, Vince Vielhaber wrote: On 8 Dec 2002, Oliver Elphick wrote: If something is familiar, it feels safe. We need to make PostgreSQL familiar. That's why we need marketing. Then why wasn't mysql in the list? It's familiar. To PHBs? MySQL doesn't have anything like the marketing clout of Oracle and IBM. Be thankful it isn't in the list; it would make it a hell of a lot more difficult to dislodge it. If we want people to use PostgreSQL in preference to anything else, we have to make it known. That is marketing. If we believe we have a good product we need to say so and say why and how it's better, cheaper and purer than anything else. If there's no good marketing, bad marketing will rule the world for sure. If we don't care, we can retreat into a pure technological huddle and disappear up our own navels. The rest of the world won't even notice. Such purity will eventually destroy the project because it will lose the momentum for growth through a lack of new input. You can grow or you can decline; a steady state is almost impossible to achieve. -- Oliver Elphick[EMAIL PROTECTED] Isle of Wight, UK http://www.lfix.co.uk/oliver GPG: 1024D/3E1D0C1C: CA12 09E0 E8D5 8870 5839 932A 614D 4C34 3E1D 0C1C For I am the LORD your God; ye shall therefore sanctify yourselves, and ye shall be holy; for I am holy. Leviticus 11:44 ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] [GENERAL] PostgreSQL Global Development Group
Oliver Elphick wrote: If we want people to use PostgreSQL in preference to anything else, we have to make it known. That is marketing. If we believe we have a good product we need to say so and say why and how it's better, cheaper and purer than anything else. If there's no good marketing, bad marketing will rule the world for sure. If we don't care, we can retreat into a pure technological huddle and disappear up our own navels. The rest of the world won't even notice. Such purity will eventually destroy the project because it will lose the momentum for growth through a lack of new input. You can grow or you can decline; a steady state is almost impossible to achieve. Couldn't agree more with that last point. I've had the perspective of working in big companies using various database software, a company specifically focused on PostgreSQL (Great Bridge), and now a new ISV with PostgreSQL underneath a vertical application (OpenMFG). I can tell you that even though the pgsql-hacker community is as strong as it's ever been, I think there's a serious danger of the larger world passing PostgreSQL by. Oracle and DB2 continue to get better and - significantly - cheaper, and SQL Server ... well, Oracle and DB2 are getting better. MySQL, even though it's an inferior product for most real database work, has always had a significantly larger installed base than PostgreSQL- and it's less controversial for people like Sun (who have deep relationships with Oracle) to get involved with. And despite the productizing of RHDB, Red Hat doesn't seem interested in making a real push for PostgreSQL either. While there are a number of smaller companies trying to help out, I think it's clear that the burden for helping PostgreSQL to find wider acceptance in the marketplace will be on the pgsql-hacker community for some time to come. I applaud the efforts of the advocacy group, and encourage others here not to look at the marketing as somehow dirty or beneath the dignity of the project. Keep up the good work, Ned ---(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] [GENERAL] PostgreSQL Global Development Group
On 8 Dec 2002, Oliver Elphick wrote: On Sun, 2002-12-08 at 22:27, Vince Vielhaber wrote: On 8 Dec 2002, Oliver Elphick wrote: If something is familiar, it feels safe. We need to make PostgreSQL familiar. That's why we need marketing. Then why wasn't mysql in the list? It's familiar. To PHBs? I would argue yes. Everywhere you turn you see Powered by MySQL. If years of working on it isn't getting them the familiarity to overcome the PHBs then the PHBs are either not considering open source or the marketing attempts aren't strong or capable enough to penetrate. Vince. -- Fast, inexpensive internet service 56k and beyond! http://www.pop4.net/ http://www.meanstreamradio.com http://www.unknown-artists.com Internet radio: It's not file sharing, it's just radio. ---(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] [GENERAL] PostgreSQL Global Development Group
On Sunday 08 December 2002 06:14 pm, Vince Vielhaber wrote: On 8 Dec 2002, Oliver Elphick wrote: On Sun, 2002-12-08 at 22:27, Vince Vielhaber wrote: On 8 Dec 2002, Oliver Elphick wrote: If something is familiar, it feels safe. We need to make PostgreSQL familiar. That's why we need marketing. Then why wasn't mysql in the list? It's familiar. To PHBs? I would argue yes. Everywhere you turn you see Powered by MySQL. If years of working on it isn't getting them the familiarity to overcome the PHBs then the PHBs are either not considering open source or the marketing attempts aren't strong or capable enough to penetrate. I don't think mysql has penetrated the enterprise class/ mission critical mindest, which is the level our service had to be provided that. To be honest, it was tough to argue PostgreSQL belonged in that group, though we had a good 2 years worth of history in actually running the business on PostgreSQL which couldn't be dismissed. Of course, some of these companies weren't too happy things were running on linux, and not aix or solaris; are we seeing a pointy haired trend here? Personally I never understood why our sales guys didn't just tell them ok we'll port the service to oracle/solaris for you, but it's going to cost you at least twice what it does now, if not three times. Oh, and you won't see any better performance. Robert Treat ---(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] [GENERAL] PostgreSQL Global Development Group
On Saturday 07 December 2002 11:10 pm, Vince Vielhaber wrote: On 5 Dec 2002, Robert Treat wrote: On Thu, 2002-12-05 at 03:28, Dave Page wrote: www is a closed group consisting of a few of us who actually do the work on the sites. This is one of the primary reasons the sites are so fractured. We have 4 different mailing lists for website development (and I'm not counting advocacy as one of those) and the folks maintaining those lists seem to be against letting anyone into their fiefdoms. Well we told you a few times which list you were supposed to subscribe to but over and over again you didn't. I just finished approving your subscription to the list we've been telling you to join. And I have multiple subscription denied emails from lists I've tried to join. In fact I was just rejected again from joining pgsql-www. Given that I'm one of the few people who have actually donated content and/or code to techdocs, advocacy, and the new portal site; not to mention I already have shell access for the backend servers; also not to mention my helping out with the sourceforge PostgreSQL project page; and finally not to mention my solid open source background which includes coding for the phpPgAdmin project and work as a php foundry administrator for sourceforge, among other projects; I have to ask what the hell could be so secretive and important about that list that people would complain about lack of communication and yet I can't be allowed access to that group?!? Robert Treat ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] [GENERAL] PostgreSQL Global Development Group
On Sun, 8 Dec 2002, Robert Treat wrote: On Saturday 07 December 2002 11:10 pm, Vince Vielhaber wrote: On 5 Dec 2002, Robert Treat wrote: On Thu, 2002-12-05 at 03:28, Dave Page wrote: www is a closed group consisting of a few of us who actually do the work on the sites. This is one of the primary reasons the sites are so fractured. We have 4 different mailing lists for website development (and I'm not counting advocacy as one of those) and the folks maintaining those lists seem to be against letting anyone into their fiefdoms. Well we told you a few times which list you were supposed to subscribe to but over and over again you didn't. I just finished approving your subscription to the list we've been telling you to join. And I have multiple subscription denied emails from lists I've tried to join. In fact I was just rejected again from joining pgsql-www. Given that I'm one of the few people who have actually donated content and/or code to techdocs, advocacy, and the new portal site; not to mention I already have shell access for the backend servers; also not to mention my helping out with the sourceforge PostgreSQL project page; and finally not to mention my solid open source background which includes coding for the phpPgAdmin project and work as a php foundry administrator for sourceforge, among other projects; I have to ask what the hell could be so secretive and important about that list that people would complain about lack of communication and yet I can't be allowed access to that group?!? Exactly, and pgsql-www is the wrong goddam list! I've told you over and over again. pgsql-www is the list that the group leaders use to collaborate. Over and over again we told you to join pgsql-www-main, which is an invitation only list for development of the soon to be released portal. I'm the one that approves or denies the subscriptions to BOTH of those lists and the first time I denied you I sent you a note telling you not only why I denied it, but which list you were SUPPOSED to join. Vince. -- Fast, inexpensive internet service 56k and beyond! http://www.pop4.net/ http://www.meanstreamradio.com http://www.unknown-artists.com Internet radio: It's not file sharing, it's just radio. ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] [GENERAL] PostgreSQL Global Development Group
On Sunday 08 December 2002 11:32 pm, Vince Vielhaber wrote: Exactly, and pgsql-www is the wrong goddam list! I've told you over and over again. pgsql-www is the list that the group leaders use to collaborate. And a fine job of collaboration you're doing *obviously* Over and over again we told you to join pgsql-www-main, which is an invitation only list for development of the soon to be released portal. I'm the one that approves or denies the subscriptions to BOTH of those lists and the first time I denied you I sent you a note telling you not only why I denied it, but which list you were SUPPOSED to join. fiefdoms!! Robert Treat ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] [GENERAL] PostgreSQL Global Development Group
Vince, Peter: I can definitely understand someone not wanting to *participate* in marketing/advocacy of PostgreSQL. However, your being opposed to promoting PostgreSQL as an organized activity *at all* baffles me. How can you be against promoting PostgreSQL? Don't you want poeple to use your code? For me, it's not just a matter of preference, but of necessity; if Postgres becomes obscure, I stop being able to participate in the project. While there are people on this list who are fortunate enough to be able to code whatever they want and still get paid, for a lot of people, our participation hinges on the cycle: Postgres Users -- Postgres Contracts -- Postgres Jobs -- Postgres Contributors -- Improvement *and Promotion* of Postgres -- Postgres Users ... The Promotion part of that step is *not* dispensable; all of the best features in the world are not going to expand the Postgres commmunity if people haven't heard of it, can't find it, and know a lot more about MySQL anyway. While this may not be true for everybody, some of us have clients or bosses who do read trade periodicals and demand that we follow their technology reccomendations. I already have one client using MySQL because of MySQL's much more professional web site and better support and better performance. Frankly, if we blow off marketing PostgreSQL as irrelevant, we *deserve* to get steamrollered by MySQL. I think it's terrific that Postgres is a real, programmer-centric, democratic Open Source project. I believe that programmers and contributors should lead the project, and decide features and schedules based on technical and not marketing reasons. Nobody on the Advocacy team is trying to take control of the project and turn it into a dot-com. But once Postgres has been packaged, we need to have a group making a loud enough noise to get the world to pay attention. I'm not asking everyone on this list to participate, but I am asking everyone on this list to recognize the utility of the effort. -Josh Berkus ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
[HACKERS] bison error
hi, When I check out the pgsql from cvs and I complile it, an error occured . dir: pgsql/src/interfaces/ecpg/preproc bison -y -d preproc.y erro information: preproc.y:5559: fatal error: maximum table size (32767) exceeded. However, I used the source from the ftp, find preproc.c in there. gmake will skip the step(bison -y -d preproc.y) and succeeded. who can tell me why? ¡¡ 2002-12-09 ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] bison error
On Mon, 2002-12-09 at 01:58, bigapple wrote: When I check out the pgsql from cvs and I complile it, an error occured . dir: pgsql/src/interfaces/ecpg/preproc bison -y -d preproc.y erro information: preproc.y:5559: fatal error: maximum table size (32767) exceeded. You need to use Bison 1.50 or greater, due to a limitation in previous versions of Bison. Cheers, Neil -- Neil Conway [EMAIL PROTECTED] || PGP Key ID: DB3C29FC ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] bison error
bigapple wrote: hi, When I check out the pgsql from cvs and I complile it, an error occured . dir: pgsql/src/interfaces/ecpg/preproc bison -y -d preproc.y erro information: preproc.y:5559: fatal error: maximum table size (32767) exceeded. You need at least version 1.5 of bison. Last time I checked, the latest out was 1.75 However, I used the source from the ftp, find preproc.c in there. gmake will skip the step(bison -y -d preproc.y) and succeeded. who can tell me why? Source distributions contain preprocessed files so that you can compile PostgreSQL without needing bison installed. I think you only need bison if you get source code from CVS (or want to hack the grammar in the source distribution). HTH, Joe ---(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
