Re: [pgsql-www] [HACKERS] Changes to Contributor List
-Original Message- From: Josh Berkus [mailto:[EMAIL PROTECTED] Sent: 05 November 2003 22:27 To: Bruce Momjian; Tom Lane Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Re: [pgsql-www] [HACKERS] Changes to Contributor List Guys, Oh, and how about we kill the Image Map of major developers? It's about 4 years out of date, and makes developers.postgresql.org load like molasses in January. Yes please. That should reduce my email load a bit! Regards, Dave. ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] Changes to Contributor List
-Original Message- From: Peter Eisentraut [mailto:[EMAIL PROTECTED] Sent: 05 November 2003 23:11 To: Josh Berkus Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Re: [HACKERS] Changes to Contributor List Josh Berkus writes: If possible, for the upcoming release we'd like to get the Contributor List on developer.postgresql.org updated. Can everyone please take a gander at: http://developer.postgresql.org/bios.php One thing that really puzzles me is this web page: http://advocacy.postgresql.org/about/ Personnally I don't see why that whole site isn't part of the main site. Regards, Dave. ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] Changes to Contributor List
Josh Berkus writes: Yeah, you're right,it's confusing we should have two seperate pages, one for What is the PGDG possibly linking to developer., and one page for Contact Us. As it is, they two are munged together. Btw., what process is used to determine which organizations become a recognised contributor? -- Peter Eisentraut [EMAIL PROTECTED] ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [pgsql-www] [HACKERS] Changes to Contributor List
Emeritus is verbatin from Latin and is really very spread into most Western languages. -- Paulo Scardine I think the Emeritus word might be too hard for non-native English speakers, and even for less educated English speakers. ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
[HACKERS] Information Schema and constraint names not unique
Just looking at the information schema in 7.4 and noticed something odd/annoying/problematic: create table pk(f1 int primary key); create table fk1(f1 int references pk(f1)); create table fk2(f1 int references pk(f1)); select * from information_schema.referential_constraints; -[ RECORD 1 ]-+-- constraint_catalog| test constraint_schema | public constraint_name | $1 unique_constraint_catalog | test unique_constraint_schema | public unique_constraint_name| pk_pkey match_option | NONE update_rule | NO ACTION delete_rule | NO ACTION -[ RECORD 2 ]-+-- constraint_catalog| test constraint_schema | public constraint_name | $1 unique_constraint_catalog | test unique_constraint_schema | public unique_constraint_name| pk_pkey match_option | NONE update_rule | NO ACTION delete_rule | NO ACTION Notice that the two records are identical because the two constraint names are the same. ISTM that we should have a way of usefully examining specific constraints without having to name them. Can we add the constraint OID or some other identifier (table?) or ensure that constraint names are unique? This problem applies to all the info schema tables that use constraint name. Philip Warner| __---_ Albatross Consulting Pty. Ltd. |/ - \ (A.B.N. 75 008 659 498) | /(@) __---_ Tel: (+61) 0500 83 82 81 | _ \ Fax: (+61) 03 5330 3172 | ___ | Http://www.rhyme.com.au |/ \| |---- PGP key available upon request, | / and from pgp5.ai.mit.edu:11371 |/ ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [pgsql-www] [HACKERS] Changes to Contributor List
On Thu, 2003-11-06 at 03:21, Dave Page wrote:
-Original Message-
From: Peter Eisentraut [mailto:[EMAIL PROTECTED]
Sent: 05 November 2003 23:11
To: Josh Berkus
Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]
Subject: Re: [HACKERS] Changes to Contributor List
Josh Berkus writes:
If possible, for the upcoming release we'd like to get the
Contributor List on
developer.postgresql.org updated. Can everyone please
take a gander at:
http://developer.postgresql.org/bios.php
One thing that really puzzles me is this web page:
http://advocacy.postgresql.org/about/
Personnally I don't see why that whole site isn't part of the main site.
Because when it was originally created the guy doing the main website
and the guy doing the advocacy website weren't big on nuzzling together.
The advocacy site does have different requirements than the main site,
namely its bi-lingualness and the different target audience, but perhaps
with adding bi-lingual capabilities to the main site these two sites
could be brought together.
Robert Treat
--
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL
---(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-www] [HACKERS] Changes to Contributor List
On Thu, Nov 06, 2003 at 09:25:38AM -0500, Robert Treat wrote: The advocacy site does have different requirements than the main site, namely its bi-lingualness and the different target audience, but perhaps with adding bi-lingual capabilities to the main site these two sites could be brought together. Certainly; see the www.debian.org for an example. They have multilingual capabilities across the whole site. -- Alvaro Herrera (alvherre[a]dcc.uchile.cl) Cómo ponemos nuestros dedos en la arcilla del otro. Eso es la amistad; jugar al alfarero y ver qué formas se pueden sacar del otro (C. Halloway en La Feria de las Tinieblas, R. Bradbury) ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] Information Schema and constraint names not unique
Philip Warner [EMAIL PROTECTED] writes: Notice that the two records are identical because the two constraint names are the same. ISTM that we should have a way of usefully examining specific constraints without having to name them. Can we add the constraint OID or No. The schemas of the information_schema views are defined by the standard; I don't think we get to invent columns, especially not columns with such PG-specific contents as OIDs. some other identifier (table?) or ensure that constraint names are unique? The reason the spec defines these views this way is that it expects constraint names to be unique across a whole schema. We don't enforce that, and I don't think we want to start doing so (that was already proposed and shot down at least once). You are of course free to use constraint names that are distinct if you want to follow the spec's lead. regards, tom lane ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] Very poor estimates from planner
Rod Taylor [EMAIL PROTECTED] writes: - Hash Join (cost=3D1230.79..60581.82 rows=3D158 width=3D54)= (actual time=3D1262.35..151200.29 rows=3D1121988 loops=3D1) Hash Cond: (outer.account_id =3D inner.account_id) - Hash Join (cost=3D1226.78..52863.43 rows=3D1542558 w= idth=3D50) (actual time=3D1261.63..100418.30 rows=3D1573190 loops=3D1) (join of bsod, tsb, tss) (btw, would you mind turning off MIME encoding in your mails to the PG lists? It's a real PITA to quote.) So yes, since this is a full table scan all values will be joined since the foreign key enforces them all to exist. Well, no, because only 1121988 rows come out of the join when 1573190 went in. So the actual selectivity of the join is about 70%. The question is why the planner is estimating the selectivity at 0.01% (158/1542558). Could we see the pg_stats rows for service.account_id and account.account_id? regards, tom lane ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Information Schema and constraint names not unique
Tom Lane wrote: The reason the spec defines these views this way is that it expects constraint names to be unique across a whole schema. We don't enforce that, and I don't think we want to start doing so (that was already proposed and shot down at least once). You are of course free to use constraint names that are distinct if you want to follow the spec's lead. Would a good halfway house be to ensure that generated names were unique within a schema (e.g. instead of generating $1 generate tablename$1)? I know this might make looking to see if something is a generated constraint mildly harder. It would have the advantage of a slightly more meaningful name on the constraint. Doing that we still wouldn't enforce the spec's requirements for uniqueness of constraint names within a schema (which are arguably silly), but wouldn't violate them ourselves. (I'm sure there are wrinkles I haven't thought of, though. Not sure about what it would do to backwards compatibility, for instance.) cheers andrew ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Information Schema and constraint names not unique
Andrew Dunstan [EMAIL PROTECTED] writes: The reason the spec defines these views this way is that it expects constraint names to be unique across a whole schema. We don't enforce that, and I don't think we want to start doing so (that was already proposed and shot down at least once). Would a good halfway house be to ensure that generated names were unique within a schema (e.g. instead of generating $1 generate tablename$1)? No, because that buys into all of the serialization and deadlocking problems that doing it the spec's way entail --- essentially, you cannot add a new constraint without obtaining some kind of schema-wide lock. See prior discussions. 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] Information Schema and constraint names not unique
Tom Lane writes: Would a good halfway house be to ensure that generated names were unique within a schema (e.g. instead of generating $1 generate tablename$1)? No, because that buys into all of the serialization and deadlocking problems that doing it the spec's way entail I don't think we really need a method to guarantee unique names. It would already help a lot if we just added the table name, or something that was until a short time before the action believed to be the table name, or even only the table OID, before (or after) the $1. -- Peter Eisentraut [EMAIL PROTECTED] ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] Information Schema and constraint names not unique
Peter Eisentraut [EMAIL PROTECTED] writes: I don't think we really need a method to guarantee unique names. It would already help a lot if we just added the table name, or something that was until a short time before the action believed to be the table name, or even only the table OID, before (or after) the $1. I don't have a problem with switching from $1 to tablename_$1, or some such, for auto-generated constraint names. But if it's not guaranteed unique, does it really satisfy Philip's concern? regards, tom lane ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] Information Schema and constraint names not unique
On Thu, Nov 06, 2003 at 11:42:13AM -0500, Tom Lane wrote: Peter Eisentraut [EMAIL PROTECTED] writes: I don't think we really need a method to guarantee unique names. It would already help a lot if we just added the table name, or something that was until a short time before the action believed to be the table name, or even only the table OID, before (or after) the $1. I don't have a problem with switching from $1 to tablename_$1, or some such, for auto-generated constraint names. But if it's not guaranteed unique, does it really satisfy Philip's concern? It certainly _is_ unique within a schema ... (But what happens to the constraint name when the table is renamed?) -- Alvaro Herrera (alvherre[a]dcc.uchile.cl) No renuncies a nada. No te aferres a nada. ---(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] Changes to Contributor List
Peter, Btw., what process is used to determine which organizations become a recognised contributor? Yeah, that's another ToDo item ... your company needs to go up there. Criteria are major code contributions and/or sponsoring a full-time developer. We've discussed it on -CORE some, but not come to a specific determination of the level required. However, between you M LinuxWorld etc. your company definitely qualifies. And if we're gonna continue this thread, we should move it to -Advocacy. -- 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] Information Schema and constraint names not unique
Alvaro Herrera [EMAIL PROTECTED] writes: On Thu, Nov 06, 2003 at 11:42:13AM -0500, Tom Lane wrote: I don't have a problem with switching from $1 to tablename_$1, or some such, for auto-generated constraint names. But if it's not guaranteed unique, does it really satisfy Philip's concern? It certainly _is_ unique within a schema ... (But what happens to the constraint name when the table is renamed?) Exactly. Also consider manually-assigned constraint names that happen to look like foo_$n --- these could cause trouble if table foo is created later. To make a guarantee of uniqueness would require more infrastructure than just a simple hack of the constraint name generator logic. BTW we also have some problems with auto-generated names for column constraints; these generally look like tablename_columnname, and that's not unique: regression=# create table foo (f1 int check (f1 0) check (f1 10)); ERROR: check constraint foo_f1 already exists regards, tom lane ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] Information Schema and constraint names not unique
Tom Lane wrote: Peter Eisentraut [EMAIL PROTECTED] writes: I don't think we really need a method to guarantee unique names. It would already help a lot if we just added the table name, or something that was until a short time before the action believed to be the table name, or even only the table OID, before (or after) the $1. I don't have a problem with switching from $1 to tablename_$1, or some such, for auto-generated constraint names. But if it's not guaranteed unique, does it really satisfy Philip's concern? He wouldn't see identical rows returned from his query any more, would he? My point was that doing this nothing would prevent the user creating duplicate constraint names but the system would not produce (or would be most unlikely to produce) duplicates. I read the thread from last year on Google at http://groups.google.com/groups?hl=enlr=ie=UTF-8threadm=18252.1025635125%40sss.pgh.pa.usrnum=1prev=/groups%3Fq%3Dunique%2Bconstraint%2Bnames%2Bgroup:comp.databases.postgresql.hackers%2Bgroup:comp.databases.postgresql.hackers%2Bgroup:comp.databases.postgresql.hackers%2Bgroup:comp.databases.postgresql.hackers%26hl%3Den%26lr%3D%26ie%3DUTF-8%26group%3Dcomp.databases.postgresql.hackers%26selm%3D18252.1025635125%2540sss.pgh.pa.us%26rnum%3D1 which was why I thought this would be a move in the right direction without encountering those problems. (I much prefer using tablename to OID, BTW) cheers andrew ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] Changes to Contributor List
Josh Berkus writes: And if we're gonna continue this thread, we should move it to -Advocacy. I'm a bit lost here. It was recently said very clearly, The target audience of the advocacy site is PHB's, not technical people. And the content of the site supports that in my mind. Yet, the advocacy group keeps absorbing more and more tasks that are not strictly related to development, but are clearly not targeting PHB's exclusively either. There is a wide spectrum between the PostgreSQL guru on the one side and the PHB on the other side. (And the middle of the spectrum happens to be the largest part.) Those are the people I see coming to presentations, expositions, those are the people I am targeting when I'm making flyers, write books and magazine articles, prepare training classes. Those are the people who actually come to our web site in search of information. Those are the people who will like to read a nice press release that is not a bare change log but still free of marketing BS. But nobody's addressing those people. So please, declare your intentions and make them consistent with your actions. Until then, or in any case, the discussion list of the development group is the right place to discuss who gets to be a recognized contributor of that same development group. -- Peter Eisentraut [EMAIL PROTECTED] ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [pgsql-www] [HACKERS] Changes to Contributor List
-Original Message- From: Alvaro Herrera [mailto:[EMAIL PROTECTED] Sent: 06 November 2003 14:47 To: Robert Treat Cc: Dave Page; Peter Eisentraut; Josh Berkus; [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Re: [pgsql-www] [HACKERS] Changes to Contributor List On Thu, Nov 06, 2003 at 09:25:38AM -0500, Robert Treat wrote: The advocacy site does have different requirements than the main site, namely its bi-lingualness and the different target audience, but perhaps with adding bi-lingual capabilities to the main site these two sites could be brought together. Certainly; see the www.debian.org for an example. They have multilingual capabilities across the whole site. We nearly do on ours. Andreas has done quite a bit of work on it. Regards, Dave. ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] Changes to Contributor List
Peter, I'm a bit lost here. I was discussing specifically the Recognized Corporate Contributors which is, AFAIK, strictly a PHB thing, no? -- -Josh Berkus Aglio Database Solutions San Francisco ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] Changes to Contributor List
Josh Berkus writes: I was discussing specifically the Recognized Corporate Contributors which is, AFAIK, strictly a PHB thing, no? No. -- Peter Eisentraut [EMAIL PROTECTED] ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
[Fwd: Re: [HACKERS] Very poor estimates from planner]
On Thu, 2003-11-06 at 10:35, Tom Lane wrote:
Rod Taylor [EMAIL PROTECTED] writes:
- Hash Join (cost=3D1230.79..60581.82 rows=3D158 width=3D54)=
(actual time=3D1262.35..151200.29 rows=3D1121988 loops=3D1)
Hash Cond: (outer.account_id =3D inner.account_id)
- Hash Join (cost=3D1226.78..52863.43 rows=3D1542558 w=
idth=3D50) (actual time=3D1261.63..100418.30 rows=3D1573190 loops=3D1)
(join of bsod, tsb, tss)
(btw, would you mind turning off MIME encoding in your mails to the PG
lists? It's a real PITA to quote.)
I can, though I would ask which email client you use that doesn't pull
content out of mime encoded emails.
So yes, since this is a full table scan all values will be joined since
the foreign key enforces them all to exist.
Well, no, because only 1121988 rows come out of the join when 1573190
went in. So the actual selectivity of the join is about 70%. The
question is why the planner is estimating the selectivity at 0.01%
(158/1542558).
Could we see the pg_stats rows for service.account_id and
account.account_id?
relname | attname | stanullfrac | stawidth | stadistinct | stakind1
| stakind2 | stakind3 | stakind4 | staop1 | staop2 | staop3 | staop4
|
stanumbers1| stanumbers2 |
stanumbers3 | stanumbers4 |
stavalues1| stavalues2 | stavalues3 |
stavalues4
-++-+--+-+--+--+--+--+++++--+-+-+-+-+++
service | account_id | 0 |4 | 10 |1
|3 |0 |0 | 96 | 97 | 0 | 0 |
{0.388393,0.0825893,0.078125,0.0758929,0.0703125,0.0647321,0.0647321,0.0636161,0.0625,0.0491071}
| {0.591672} | | |
{1,8221,8223,8226,8222,8218,8220,8219,8224,8225}|| |
account | account_id | 0 |4 | -1 |2
|3 |0 |0 | 97 | 97 | 0 | 0
|
| {0.97034} | | |
{1,10178,12136,14099,16054,18011,19966,21924,23881,26018,27995} || |
(2 rows)
--
Rod Taylor rbt [at] rbt [dot] ca
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL
PGP Key: http://www.rbt.ca/rbtpub.asc
---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Changes to Contributor List
Peter, I was discussing specifically the Recognized Corporate Contributors which is, AFAIK, strictly a PHB thing, no? No. Please explain. -- -Josh Berkus Aglio Database Solutions San Francisco ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] [Fwd: Re: Very poor estimates from planner]
Could we see the pg_stats rows for service.account_id and account.account_id? Sorry, ignore previous numbers. My prior tests were done in a transaction (to roll back stats changes) and I forgot to re-analyze. relname | attname | stanullfrac | stawidth | stadistinct | stakind1 | stakind2 | stakind3 | stakind4 | staop1 | staop2 | staop3 | staop4 | stanumbers1 | stanumbers2 | stanumbers3 | stanumbers4 | stavalues1
[HACKERS] Bogus bind() warnings
When I start up with -i, I get the following log: LOG: could not bind IPv4 socket: Address already in use HINT: Is another postmaster already running on port 5432? If not, wait a few seconds and retry. LOG: database system was shut down at 2003-11-06 20:47:54 CET LOG: checkpoint record is at 0/9B6E08 LOG: redo record is at 0/9B6E08; undo record is at 0/0; shutdown TRUE LOG: next transaction ID: 538; next OID: 17143 LOG: database system is ready There is no other postmaster running anywhere. I suspect that this has to do with IPv6. This is a SuSE 8.something machine that is relatively fully IPv6 enabled. -- Peter Eisentraut [EMAIL PROTECTED] ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [HACKERS] Bogus bind() warnings
Peter Eisentraut [EMAIL PROTECTED] writes: When I start up with -i, I get the following log: LOG: could not bind IPv4 socket: Address already in use There is no other postmaster running anywhere. I suspect that this has to do with IPv6. This is a SuSE 8.something machine that is relatively fully IPv6 enabled. Is it possible that that kernel considers binding to an IPv6 port to conflict with binding to the same port number as an IPv4 port? IIRC that was the behavior we once expected would happen, but later found out that most kernels don't (yet?) act that way. The present design of trying to bind to both IPv6 and IPv4 sockets would be unnecessary if the kernels acted more rationally. regards, tom lane ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] [pgsql-advocacy] Changes to Contributor List
Josh Berkus writes: I was discussing specifically the Recognized Corporate Contributors which is, AFAIK, strictly a PHB thing, no? No. Please explain. I don't see anything in this project that should be strictly a PHB thing, the exception maybe being the weird whitepaper someone is going to write sometime. Anything else is intended for a greatly diverse audience, who may be engineers or decision makers, who may be technically incompetent, technically open-minded, or technical experts, and who may or may not have varying degrees of clues about open source, databases, and PostgreSQL. In other words, the general public. If you disagree, then maybe we should split up into advocacy-for-phbs and advocacy-for-real-people groups. Moreover, you seem to imply that the list of companies should primarily be a marketing instrument of the PostgreSQL project for attracting new users. I don't understand that. I would understand it if the list contained a large number of big names, but it does not, and it is not set up to strive for that goal. Right now, the list is nothing more than a marketing tool for the listed companies for attracting existing users to them. I think that list is a pretty dumb idea in the first place. We have a list of developers with company names next to them. Let readers make their own recognition evaluation. -- Peter Eisentraut [EMAIL PROTECTED] ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [HACKERS] [pgsql-advocacy] Changes to Contributor List
Peter Eisentraut [EMAIL PROTECTED] writes: I think that list is a pretty dumb idea in the first place. We have a list of developers with company names next to them. Let readers make their own recognition evaluation. That works if you think that the only form of corporate support is sponsoring a developer. Seems to me that's a bit narrow-minded. For instance, hub.org is contributing (by providing hosting services) way more than you might think from the number of times it appears on the developer list... regards, tom lane ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] [pgsql-advocacy] Changes to Contributor List
On Thu, Nov 06, 2003 at 09:08:57PM +0100, Peter Eisentraut wrote: I think that list is a pretty dumb idea in the first place. We have a list of developers with company names next to them. Let readers make their own recognition evaluation. I'm not sure that's all it's for. Every time we talk about using Postgres, people want to know who else uses it. It's really strange, but for some reason, people seem to believe that a product isn't any good unless a large number of people are already using it, and that it _is_ good if a large number of people do use it. (I guess the idea is that all those Windows users can't be wrong. Oh, wait. . .) A -- Andrew Sullivan 204-4141 Yonge Street Afilias CanadaToronto, Ontario Canada [EMAIL PROTECTED] M2P 2A8 +1 416 646 3304 x110 ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] [pgsql-advocacy] Changes to Contributor List
Hello, My feeling is that advocacy should be just that: Advocacy. It doesn't matter who the intended audience is in reality. However, it is also important to remember that technical experts typically don't need to be sold on PostgreSQL. PHBs on the other hand probably do and thus much of our Advocacy work should be geared towards them. I believe one place where we are particularly week is PostgreSQL versus MySQL. We should have mountains of dead tree printables on why you should use PostgreSQL and why you shouldn't use mySQL. This can be done in a non-flammatory way. Sincerely, Joshua Drake Peter Eisentraut wrote: Josh Berkus writes: I was discussing specifically the Recognized Corporate Contributors which is, AFAIK, strictly a PHB thing, no? No. Please explain. I don't see anything in this project that should be strictly a PHB thing, the exception maybe being the weird whitepaper someone is going to write sometime. Anything else is intended for a greatly diverse audience, who may be engineers or decision makers, who may be technically incompetent, technically open-minded, or technical experts, and who may or may not have varying degrees of clues about open source, databases, and PostgreSQL. In other words, the general public. If you disagree, then maybe we should split up into advocacy-for-phbs and advocacy-for-real-people groups. Moreover, you seem to imply that the list of companies should primarily be a marketing instrument of the PostgreSQL project for attracting new users. I don't understand that. I would understand it if the list contained a large number of big names, but it does not, and it is not set up to strive for that goal. Right now, the list is nothing more than a marketing tool for the listed companies for attracting existing users to them. I think that list is a pretty dumb idea in the first place. We have a list of developers with company names next to them. Let readers make their own recognition evaluation. -- Command Prompt, Inc., home of Mammoth PostgreSQL - S/ODBC and S/JDBC Postgresql support, programming shared hosting and dedicated hosting. +1-503-222-2783 - [EMAIL PROTECTED] - http://www.commandprompt.com Editor-N-Chief - PostgreSQl.Org - http://www.postgresql.org ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] Bogus bind() warnings
Tom Lane writes: Is it possible that that kernel considers binding to an IPv6 port to conflict with binding to the same port number as an IPv4 port? I don't understand this business, but if it helps, below is my ifconfig output. eth0 Link encap:Ethernet HWaddr 00:40:F6:74:BE:71 inet6 addr: fe80::240:f6ff:fe74:be71/10 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:440903 errors:0 dropped:0 overruns:0 frame:0 TX packets:301944 errors:5 dropped:0 overruns:0 carrier:3 collisions:0 txqueuelen:100 RX bytes:189774879 (180.9 Mb) TX bytes:64786361 (61.7 Mb) Interrupt:11 Base address:0xd800 eth1 Link encap:Ethernet HWaddr 00:50:22:80:A9:6E inet addr:192.168.100.1 Bcast:192.168.100.255 Mask:255.255.255.0 inet6 addr: fe80::250:22ff:fe80:a96e/10 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:99975 errors:0 dropped:0 overruns:0 frame:0 TX packets:126153 errors:0 dropped:0 overruns:0 carrier:0 collisions:8425 txqueuelen:100 RX bytes:15633278 (14.9 Mb) TX bytes:52753463 (50.3 Mb) Interrupt:9 Base address:0x9000 loLink encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 inet6 addr: ::1/128 Scope:Host UP LOOPBACK RUNNING MTU:16436 Metric:1 RX packets:107127 errors:0 dropped:0 overruns:0 frame:0 TX packets:107127 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:20827790 (19.8 Mb) TX bytes:20827790 (19.8 Mb) ppp0 Link encap:Point-to-Point Protocol inet addr:82.82.161.250 P-t-P:145.253.4.3 Mask:255.255.255.255 UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1492 Metric:1 RX packets:37103 errors:0 dropped:0 overruns:0 frame:0 TX packets:23882 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:3 RX bytes:4652420 (4.4 Mb) TX bytes:5807647 (5.5 Mb) sit0 Link encap:IPv6-in-IPv4 NOARP MTU:1480 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:0 (0.0 b) TX bytes:0 (0.0 b) -- Peter Eisentraut [EMAIL PROTECTED] ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] [pgsql-advocacy] Changes to Contributor List
Andrew Sullivan wrote: On Thu, Nov 06, 2003 at 09:08:57PM +0100, Peter Eisentraut wrote: I think that list is a pretty dumb idea in the first place. We have a list of developers with company names next to them. Let readers make their own recognition evaluation. Your assuming that people are intelligent. In general they are not. In general people want to see that Cisco, Afilias, RedHat, ACS etc... use PostgreSQL. They want graphics, they want teddy bears. J I'm not sure that's all it's for. Every time we talk about using Postgres, people want to know who else uses it. It's really strange, but for some reason, people seem to believe that a product isn't any good unless a large number of people are already using it, and that it _is_ good if a large number of people do use it. (I guess the idea is that all those Windows users can't be wrong. Oh, wait. . .) A -- Command Prompt, Inc., home of Mammoth PostgreSQL - S/ODBC and S/JDBC Postgresql support, programming shared hosting and dedicated hosting. +1-503-222-2783 - [EMAIL PROTECTED] - http://www.commandprompt.com Editor-N-Chief - PostgreSQl.Org - http://www.postgresql.org ---(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] Bogus bind() warnings
Peter Eisentraut [EMAIL PROTECTED] writes: I don't understand this business, but if it helps, below is my ifconfig output. Hmm, you have a bunch of addresses don't you? It looks like we should have included more information in the report of bind failures, like exactly which address failed. Can you step through StreamServerPort, or perhaps just strace postmaster startup, to observe the sequence of bind() calls? It would be useful to know which addresses have already been bound and which one is failing. regards, tom lane ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Bogus bind() warnings
Tom Lane wrote: Peter Eisentraut [EMAIL PROTECTED] writes: When I start up with -i, I get the following log: LOG: could not bind IPv4 socket: Address already in use There is no other postmaster running anywhere. I suspect that this has to do with IPv6. This is a SuSE 8.something machine that is relatively fully IPv6 enabled. Is it possible that that kernel considers binding to an IPv6 port to conflict with binding to the same port number as an IPv4 port? IIRC that was the behavior we once expected would happen, but later found out that most kernels don't (yet?) act that way. The present design of trying to bind to both IPv6 and IPv4 sockets would be unnecessary if the kernels acted more rationally. I have seen this before, and reported it, but can't find the thread right now. On Linux with IP6 enabled, IP4 is tunnelled over IP6 - they *are* the same sockets, AFAIK. Didn't we put in a patch after lengthy discussion that fixes things from a pg_hba.conf POV exactly to handle this (i.e. to match an IP4 address in the file with the corresponding IP6 address: n.n.n.n/x - :::n.n.n.n/96+x )? I also recall someone saying this would change in later versions of Linux. cheers andrew ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] [pgsql-advocacy] Changes to Contributor List
Peter, Right now, the list is nothing more than a marketing tool for the listed companies for attracting existing users to them. Yes? That's exactly the intention -- so that existing users and interested parties can see the companies that give major resources to the project. This has a dual purpose: it both provides free advertising for the companies as a tit-for-tat, and shows potential adopters that PostgreSQL is not 100% hobby developers coding in their free time. I think that list is a pretty dumb idea in the first place. We have a list of developers with company names next to them. Let readers make their own recognition evaluation. You seem pretty opposed to the corporate list given that one of your co-workers just requested to be on it. To paraphrase one of my friends who works for an ad agency: Peter, we're not advertising to YOU.That page is not there for you or for people like you. It is there for IT department managers, PHBs, people considering PostgreSQL, and people looking for high-end paid support. -- -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] Bogus bind() warnings
Is it possible that that kernel considers binding to an IPv6 port to conflict with binding to the same port number as an IPv4 port? Actually, I think that that may be expected behavior depending on the vintage of the kernel. Note the following comment in StreamServerPort(): /* * Note: This might fail on some OS's, like Linux older than * 2.4.21-pre3, that don't have the IPV6_V6ONLY socket option, and * map ipv4 addresses to ipv6.It will show :::ipv4 for all * ipv4 connections. */ regards, tom lane ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] [pgsql-advocacy] Changes to Contributor List
Andrew Sullivan writes: I'm not sure that's all it's for. Every time we talk about using Postgres, people want to know who else uses it. True, but for that you're looking at the wrong list. This is the list of contributors, not of users. -- Peter Eisentraut [EMAIL PROTECTED] ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] [pgsql-advocacy] Changes to Contributor List
Josh Berkus writes: Yes? That's exactly the intention -- so that existing users and interested parties can see the companies that give major resources to the project. Yes, but existing users and most interested parties don't fall into the PHB category, nor do most PHB's fall into the existing users or interested parties category, nor do most existing users fall into the group that one advocates to. Hence my original point: the list of supporting companies does not primarily belong in the advocacy realm. You seem pretty opposed to the corporate list given that one of your co-workers just requested to be on it. Well, if there must be a list, then why not be on it? :-) It is there for IT department managers, PHBs, people considering PostgreSQL, and people looking for high-end paid support. Great, that's exactly what I wanted to hear. -- Peter Eisentraut [EMAIL PROTECTED] ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] [pgsql-advocacy] Changes to Contributor List
Peter, Hence my original point: the list of supporting companies does not primarily belong in the advocacy realm. But it does! You pointed it out yourself for the hackers OSS tech people, they can just look at the descriptions of the major contributors and figure things out for themselves. They don't need a list with company logos links. This is important because we've (people on the Advocacy list) briefly discussed expanding this page to cover companies which, in the future, make *financial* contributions to PostgreSQL ... sort of a corporate donors page. This works very well in standard nonprofit fundraising; the project gets $, and the donors get publicity. Obviously, contributors would have to be categorized, but that's an issue for when we're ready to set it up. It is there for IT department managers, PHBs, people considering PostgreSQL, and people looking for high-end paid support. Great, that's exactly what I wanted to hear. I can't tell over e-mail whether you're agreeing with me or being sarcastic. Clue? -- -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
[HACKERS] postgresql-7.4RC1 - Memory fault(coredump) on HP-UX
Greetings,
PostgreSQL built with:
export CC=cc
./configure --without-readline --without-zlib
The build and install went OK.
{/opt/postgres/postgresql-7.4RC1}$ initdb -D /usr/local/pgsql/data
The files belonging to this database system will be owned by user
postgres. This user must also own the server process.
The database cluster will be initialized with locale C.
fixing permissions on existing directory /usr/local/pgsql/data... ok
creating directory /usr/local/pgsql/data/base... ok
creating directory /usr/local/pgsql/data/global... ok
creating directory /usr/local/pgsql/data/pg_xlog... ok
creating directory /usr/local/pgsql/data/pg_clog... ok
selecting default max_connections... 100
selecting default shared_buffers... 1000
creating configuration files... ok
creating template1 database in /usr/local/pgsql/data/base/1... ok
initializing pg_shadow... ok
enabling unlimited row size for system tables... ok
initializing pg_depend... ok
creating system views... ok loading pg_description... ok
creating conversions... ok
setting privileges on built-in objects... ok
creating information schema... ok
vacuuming database template1... ok
copying template1 to template0... ok
Success. You can now start the database server using:
/usr/local/pgsql/bin/postmaster -D /usr/local/pgsql/data
or
/usr/local/pgsql/bin/pg_ctl -D /usr/local/pgsql/data -l logfile start
{/opt/postgres/postgresql-7.4RC1}$ postmaster -D /usr/local/pgsql/data
Memory fault(coredump)
{/opt/postgres/postgresql-7.4RC1}$ uname -a
HP-UX systemname B.11.11 U 9000/782 2010014256 unlimited-user license
{/opt/postgres/postgresql-7.4RC1}$ id
uid=101(postgres) gid=101(postgres)
{/opt/postgres/postgresql-7.4RC1}$ ll core
-rw--- 1 postgres postgres726684 Nov 6 10:55 core
--
Reagrds,
Verbus
---(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-www] [HACKERS] Changes to Contributor List
On Thu, 2003-11-06 at 09:46, Alvaro Herrera wrote:
On Thu, Nov 06, 2003 at 09:25:38AM -0500, Robert Treat wrote:
The advocacy site does have different requirements than the main site,
namely its bi-lingualness and the different target audience, but perhaps
with adding bi-lingual capabilities to the main site these two sites
could be brought together.
Certainly; see the www.debian.org for an example. They have
multilingual capabilities across the whole site.
rant
we don't need links, we need patches
/rant
we do have this development in progress, theres just the matter of
getting time to make it happen.
Robert Treat
--
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL
---(end of broadcast)---
TIP 8: explain analyze is your friend
Re: [HACKERS] [pgsql-advocacy] Changes to Contributor List
Josh Berkus writes: But it does! You pointed it out yourself for the hackers OSS tech people, they can just look at the descriptions of the major contributors and figure things out for themselves. They don't need a list with company logos links. Other people have pointed out that this is not really sufficient. So if there is to be a separate company list, then it should be next to the individuals list. This is important because we've (people on the Advocacy list) briefly discussed expanding this page to cover companies which, in the future, make *financial* contributions to PostgreSQL ... sort of a corporate donors page. This works very well in standard nonprofit fundraising; the project gets $, and the donors get publicity. Obviously, contributors would have to be categorized, but that's an issue for when we're ready to set it up. When we're ready. But we're not. But then again, this sort of list would mostly be of use to existing users, in the sense, They support a project I like, so I like them. You could only really make use of that for attracting potential users if you could make a clear case the the amount of donations is sufficient to guarantee any kind of longevity of the project. I think that will be hard to do (because there is, in fact, absolutely no relation). But hopefully, by the time we've arrived there, this silly web site fragmentation will be over and this question will be moot. -- Peter Eisentraut [EMAIL PROTECTED] ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [HACKERS] Bogus bind() warnings
On Thu, Nov 06, 2003 at 03:42:39PM -0500, Tom Lane wrote: Is it possible that that kernel considers binding to an IPv6 port to conflict with binding to the same port number as an IPv4 port? Actually, I think that that may be expected behavior depending on the vintage of the kernel. Note the following comment in StreamServerPort(): /* * Note: This might fail on some OS's, like Linux older than * 2.4.21-pre3, that don't have the IPV6_V6ONLY socket option, and * map ipv4 addresses to ipv6.It will show :::ipv4 for all * ipv4 connections. */ Maybe my comment isn't clear enough ... It fails on Linux in case you first bind the AF_INET6 socket to ::, and then try to bind to AF_INET 0.0.0.0, and don't have the IPV6_V6ONLY options. You have this problem from the moment you enable ipv6 support in your kernel. The real fix is to get a kernel/libc that has the IPV6_V6ONLY socket option. Being unable to bind to the port isn't a problem in case you already got the AF_INET6 one. But maybe it might confuse some users who then think something is wrong. Should we just not give that error message, in case we already binded to AF_INET6 ::? Kurt ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [pgsql-www] [HACKERS] Changes to Contributor List
Robert Treat writes: rant we don't need links, we need patches /rant Let me ask you the questions that people always ask of us: How does one get involved? Where is the code? What is the plan? Where is the roadmap? Where can issues be discussed? Who is working on this? How can we help? -- Peter Eisentraut [EMAIL PROTECTED] ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
[HACKERS] Deferrable triggers
Hi Hackers I have noticed an issue with deferrable triggers not always being deferrable. Eg: alter table subsession add constraint fk_subsession_session foreign key (session_id) references session (session_id) deferrable; alter table subsession2 add constraint fk_subsession2_session foreign key (session_id) references session (session_id) on delete restrict on update restrict deferrable; select tgconstrname, tgtype, tgenabled, tgdeferrable, tginitdeferred from pg_trigger where tgisconstraint; tgconstrname | tgtype | tgenabled | tgdeferrable | tginitdeferred ++---+--+ fk_subsession_session | 21 | t | t| f fk_subsession_session | 9 | t | t| f fk_subsession_session | 17 | t | t| f fk_subsession2_session | 21 | t | t| f fk_subsession2_session | 9 | t | f| f fk_subsession2_session | 17 | t | f| f So it would seem that if I include the clauses: on delete restrict on update restrict Then the 'deferrable' which follows is only applied to creates and not to updates or deletes. Since 'restrict' is the default, the clauses aren't adding any value and can be omitted. In my case, the SQL is generated for me by PowerDesigner. My workaround is to tweak the PowerDesigner output definition to not include this line. I have seen this behaviour in both 7.2 and 7.3. Is it a bug? Or am I misunderstanding something? Regards Grant ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] Bogus bind() warnings
Kurt Roeckx [EMAIL PROTECTED] writes: Should we just not give that error message, in case we already binded to AF_INET6 ::? Seems like a cure worse than the disease to me --- it could mask real problems. I suppose we could think about dropping it from LOG to DEBUG1 level, so that it wouldn't appear in a default setup; but I'm not sure I'm for that either. Given the, ahem, wide variety of behaviors that seem to be out there, I think we'd best be happy if we have a v4/v6 implementation that has no problems worse than spurious log messages ... regards, tom lane ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [HACKERS] Deferrable triggers
On Thu, 7 Nov 2003, Grant McLean wrote: So it would seem that if I include the clauses: on delete restrict on update restrict Then the 'deferrable' which follows is only applied to creates and not to updates or deletes. Since 'restrict' is the default, the clauses aren't adding any value and can be omitted. In my case, the SQL is generated for me by PowerDesigner. My workaround is to tweak the PowerDesigner output definition to not include this line. I have seen this behaviour in both 7.2 and 7.3. Is it a bug? Or am I misunderstanding something? Restrict is not the default, there is a difference between restrict and no action. In fact I believe the main point of restrict (which IIRC was added for sql99) is to allow you to have a deferred constraint that can do immediate checking of validity on pk changes. ---(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-www] [HACKERS] Changes to Contributor List
Peter, Let me ask you the questions that people always ask of us: This isn't helping. What Robert was pointing out is that we don't currently have enough people writing HTML and PHP to finish improving the site anytime soon. Robert doesn't need managerial direction. Or did you have ambitions to be a PHB? ;-p -- -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] Bogus bind() warnings
Tom Lane wrote: Kurt Roeckx [EMAIL PROTECTED] writes: Should we just not give that error message, in case we already binded to AF_INET6 ::? Seems like a cure worse than the disease to me --- it could mask real problems. I suppose we could think about dropping it from LOG to DEBUG1 level, so that it wouldn't appear in a default setup; but I'm not sure I'm for that either. Given the, ahem, wide variety of behaviors that seem to be out there, I think we'd best be happy if we have a v4/v6 implementation that has no problems worse than spurious log messages ... I agree. Things that might be serious problems should not be hidden. Maybe it would be better to add a message that the error might be harmless if you have IPv6 turned on. 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: [HACKERS] postgresql-7.4RC1 - Memory fault(coredump) on HP-UX
Verbus Counts wrote:
{/opt/postgres/postgresql-7.4RC1}$ ll core
-rw--- 1 postgres postgres726684 Nov 6 10:55 core
Can you show us the stack trace ?
Regards
Gaetano Mendola
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] pg_stat
Nailah Ogeer wrote: Just wondering how often the stats collector resets it self. Is this a parameter i can change? At my knowledge each time that you do an analyze on your db your statistics are changed ( are not incremental I mean), anyway you can set to reset statistics at the start of postgres. Regards Gaetano Mendola ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] Deferrable triggers
On Fri, 2003-11-07 at 11:31, Stephan Szabo wrote: On Thu, 7 Nov 2003, Grant McLean wrote: So it would seem that if I include the clauses: on delete restrict on update restrict Then the 'deferrable' which follows is only applied to creates and not to updates or deletes. Since 'restrict' is the default, the clauses aren't adding any value and can be omitted. In my case, the SQL is generated for me by PowerDesigner. My workaround is to tweak the PowerDesigner output definition to not include this line. I have seen this behaviour in both 7.2 and 7.3. Is it a bug? Or am I misunderstanding something? Restrict is not the default, there is a difference between restrict and no action. In fact I believe the main point of restrict (which IIRC was added for sql99) is to allow you to have a deferred constraint that can do immediate checking of validity on pk changes. I was basing my reasoning on the CREATE TABLE documentation which says: NO ACTION Produce an error indicating that the deletion or update would create a foreign key constraint violation. This is the default action. RESTRICT Same as NO ACTION. So as you pointed out, RESTRICT is not the default, but according to the docs NO ACTION is the default and RESTRICT is the same as NO ACTION. Is the difference between the two documented anywhere? Regards Grant ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Deferrable triggers
On Thu, 7 Nov 2003, Grant McLean wrote: On Fri, 2003-11-07 at 11:31, Stephan Szabo wrote: On Thu, 7 Nov 2003, Grant McLean wrote: So it would seem that if I include the clauses: on delete restrict on update restrict Then the 'deferrable' which follows is only applied to creates and not to updates or deletes. Since 'restrict' is the default, the clauses aren't adding any value and can be omitted. In my case, the SQL is generated for me by PowerDesigner. My workaround is to tweak the PowerDesigner output definition to not include this line. I have seen this behaviour in both 7.2 and 7.3. Is it a bug? Or am I misunderstanding something? Restrict is not the default, there is a difference between restrict and no action. In fact I believe the main point of restrict (which IIRC was added for sql99) is to allow you to have a deferred constraint that can do immediate checking of validity on pk changes. I was basing my reasoning on the CREATE TABLE documentation which says: NO ACTION Produce an error indicating that the deletion or update would create a foreign key constraint violation. This is the default action. RESTRICT Same as NO ACTION. So as you pointed out, RESTRICT is not the default, but according to the docs NO ACTION is the default and RESTRICT is the same as NO ACTION. Is the difference between the two documented anywhere? Hmm, I don't think so actually. I'm surprised that we hadn't had that mistake pointed out before. The restrict entry should mention the fact that it's non-deferring. To -hackers: Is it still safe to send small documentation patches for 7.4 at this point? ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
[HACKERS] stats collector causes shared-memory-block leakage
While investigating Scott Goodwin's recent report of trouble on Mac OS
X, I have realized that we have an unpleasant little misbehavior in our
last several releases. After a backend crash, the postmaster will
attempt to recycle (delete and recreate) the old shared memory segment.
However, if the stats collector is enabled, the two stats collection
subprocesses are still attached to the old segment. Which means it
doesn't go away. Instead the postmaster will set up shop with a new
segment.
This is not so bad in a system with large SHMMAX ... but if the SHMMAX
setting is too tight to permit a second shared memory segment to be
created, the postmaster fails.
The attached patch fixes the problem by causing the stats collector to
detach from shared memory, which it isn't using anyway. Unless I hear
objections I will apply it to 7.4 and HEAD ... and I'm seriously
thinking of applying it to the 7.3 branch as well.
regards, tom lane
*** src/backend/port/sysv_shmem.c.orig Mon Oct 27 13:58:00 2003
--- src/backend/port/sysv_shmem.c Thu Nov 6 18:10:02 2003
***
*** 253,258
--- 253,261
return hdr;
}
+ /* Make sure PGSharedMemoryAttach doesn't fail without need */
+ UsedShmemSegAddr = NULL;
+
/* Loop till we find a free IPC key */
NextShmemSegID = port * 1000;
***
*** 326,341
hdr-totalsize = size;
hdr-freeoffset = MAXALIGN(sizeof(PGShmemHeader));
!
! if (ExecBackend UsedShmemSegAddr == NULL !makePrivate)
! {
! UsedShmemSegAddr = memAddress;
! UsedShmemSegID = NextShmemSegID;
! }
return hdr;
}
/*
* Attach to shared memory and make sure it has a Postgres header
--- 329,360
hdr-totalsize = size;
hdr-freeoffset = MAXALIGN(sizeof(PGShmemHeader));
! /* Save info for possible future use */
! UsedShmemSegAddr = memAddress;
! UsedShmemSegID = NextShmemSegID;
return hdr;
}
+ /*
+ * PGSharedMemoryDetach
+ *
+ * Detach from the shared memory segment, if still attached. This is not
+ * intended for use by the process that originally created the segment
+ * (it will have an on_shmem_exit callback registered to do that). Rather,
+ * this is for subprocesses that have inherited an attachment and want to
+ * get rid of it.
+ */
+ void
+ PGSharedMemoryDetach(void)
+ {
+ if (UsedShmemSegAddr != NULL)
+ {
+ if (shmdt(UsedShmemSegAddr) 0)
+ elog(LOG, shmdt(%p) failed: %m, UsedShmemSegAddr);
+ UsedShmemSegAddr = NULL;
+ }
+ }
/*
* Attach to shared memory and make sure it has a Postgres header
*** src/backend/postmaster/pgstat.c.origThu Sep 25 10:23:09 2003
--- src/backend/postmaster/pgstat.c Thu Nov 6 18:10:46 2003
***
*** 44,49
--- 44,50
#include utils/memutils.h
#include storage/backendid.h
#include storage/ipc.h
+ #include storage/pg_shmem.h
#include utils/rel.h
#include utils/hsearch.h
#include utils/ps_status.h
***
*** 399,404
--- 400,408
/* Close the postmaster's sockets, except for pgstat link */
ClosePostmasterPorts(false);
+
+ /* Drop our connection to postmaster's shared memory, as well */
+ PGSharedMemoryDetach();
pgstat_main();
*** src/include/storage/pg_shmem.h.orig Sun Aug 3 23:01:43 2003
--- src/include/storage/pg_shmem.h Thu Nov 6 18:09:50 2003
***
*** 44,48
--- 44,49
extern PGShmemHeader *PGSharedMemoryCreate(uint32 size, bool makePrivate,
int port);
extern bool PGSharedMemoryIsInUse(unsigned long id1, unsigned long id2);
+ extern void PGSharedMemoryDetach(void);
#endif /* PG_SHMEM_H */
---(end of broadcast)---
TIP 8: explain analyze is your friend
Re: [HACKERS] Information Schema and constraint names not
At 03:37 AM 7/11/2003, Peter Eisentraut wrote: It would already help a lot if we just added the table name, or something that was until a short time before the action believed to be the table name, or even only the table OID, before (or after) the $1. Can we allow/bypass the pg_* restriction, and call it pg_table-oid_n, and for pedants like me, add a DB setting that says 'enforce unique constraints' ala the spec to avoid manually created constraints being non-unique? Alternatively, I would be happy *not* to enforce constraint name uniqueness (and break the spec) so long as we also break the spec and add table OID (or something else) to the information schema (table name would be OK so long as renaming the table won't break anything). Philip Warner| __---_ Albatross Consulting Pty. Ltd. |/ - \ (A.B.N. 75 008 659 498) | /(@) __---_ Tel: (+61) 0500 83 82 81 | _ \ Fax: (+61) 03 5330 3172 | ___ | Http://www.rhyme.com.au |/ \| |---- PGP key available upon request, | / and from pgp5.ai.mit.edu:11371 |/ ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Information Schema and constraint names not
Philip Warner wrote: At 03:37 AM 7/11/2003, Peter Eisentraut wrote: It would already help a lot if we just added the table name, or something that was until a short time before the action believed to be the table name, or even only the table OID, before (or after) the $1. Can we allow/bypass the pg_* restriction, and call it pg_table-oid_n, and for pedants like me, add a DB setting that says 'enforce unique constraints' ala the spec to avoid manually created constraints being non-unique? Alternatively, I would be happy *not* to enforce constraint name uniqueness (and break the spec) so long as we also break the spec and add table OID (or something else) to the information schema (table name would be OK so long as renaming the table won't break anything). The first seems impractical for reasons given by Tom. Why provide an option for behaviour we fear could deadlock etc.? Regarding the second option, I don't understand what virtue there is in breaking the spec more, rather than embedding the table name in the constraint name. (If we do that, if the table is renamed my instinct would be to rename constraints in the renamed table with autogenerated names, but I haven't looked into it). cheers andrew ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Information Schema and constraint names not
At 10:54 AM 7/11/2003, Philip Warner wrote: add table OID (or something else) to the information schema Peter may have been alluding to this, and I misunderstood, but one idea might be to present a mangled name in the information schema; since the spec expects them to be unique, perhaps the schema should present them as unique. Downside is that named constraints would also have to be mangled. A compromise would be to only mangle the '$n' constraints, and just prepend 'pg_tablename' to the constraint name in the view. Philip Warner| __---_ Albatross Consulting Pty. Ltd. |/ - \ (A.B.N. 75 008 659 498) | /(@) __---_ Tel: (+61) 0500 83 82 81 | _ \ Fax: (+61) 03 5330 3172 | ___ | Http://www.rhyme.com.au |/ \| |---- PGP key available upon request, | / and from pgp5.ai.mit.edu:11371 |/ ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Information Schema and constraint names not
Philip Warner [EMAIL PROTECTED] writes: Peter may have been alluding to this, and I misunderstood, but one idea might be to present a mangled name in the information schema; since the spec expects them to be unique, perhaps the schema should present them as unique. Doesn't seem like this would work very well; an application that tried to do anything with the constraint names it got from the view would soon find that they were wrong. (And if you don't want to do anything with the info you get from the view, why are you bothering to look at it?) Your argument that we should add the table name to the view does have some merit though. regards, tom lane ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [pgsql-www] [HACKERS] Changes to Contributor List
Josh Berkus [EMAIL PROTECTED] writes: Peter, Let me ask you the questions that people always ask of us: This isn't helping. What Robert was pointing out is that we don't currently have enough people writing HTML and PHP to finish improving the site anytime soon. Peter appeared to be asking how additional people could get involved. Or do you *want* to keep the web group too small to get things done? 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])
[HACKERS] OpenServer 5.0.7: setsockopt(TCP_NODELAY)?
I asked my friends at SCO (who are productizing PG) to test 7.4RC1 on OpenServer 5.0.7, and received this back: A make check fails at createdb with errors in the postmaster logfile: LOG: setsockopt(TCP_NODELAY) failed: Protocol not available Plus he needed to add: if test $GCC != yes ; then CC=$CC -b elf fi to src/template/sco for 5.0.7. I downloaded 7.4 RC1 and successfully compiled it on an OpenServer 5.0.7 system. I am attaching the only change i had to make. This is the file src/template/sco. The GCC compiler on OSR5 no longer accepts the -b elf argument. Anyone of the guru's have ideas? Thanks, LER -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 972-414-9812 E-Mail: [EMAIL PROTECTED] US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749 pgp0.pgp Description: PGP signature
Re: [HACKERS] Deferrable triggers
Stephan Szabo [EMAIL PROTECTED] writes: To -hackers: Is it still safe to send small documentation patches for 7.4 at this point? Of course. Docs patches are fair game up till release (although I think Peter wants us to minimize edits to the reference pages, because regenerating the man pages is a bit of a PITA). 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] OpenServer 5.0.7: setsockopt(TCP_NODELAY)?
Larry Rosenman [EMAIL PROTECTED] writes:
A make check fails at createdb with errors in the postmaster logfile:
LOG: setsockopt(TCP_NODELAY) failed: Protocol not available
This is coming from
inton;
#ifdefTCP_NODELAY
on = 1;
if (setsockopt(port-sock, IPPROTO_TCP, TCP_NODELAY,
(char *) on, sizeof(on)) 0)
{
elog(LOG, setsockopt(TCP_NODELAY) failed: %m);
return STATUS_ERROR;
}
#endif
Better ask them what their problem is with that ...
regards, tom lane
---(end of broadcast)---
TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] Information Schema and constraint names not
At 11:38 AM 7/11/2003, Tom Lane wrote: Your argument that we should add the table name to the view does have some merit though. Sounds good to me. It would need to be added to each view that has constraint_name, then we should be able to cross the info schema views and get meaningful data. Philip Warner| __---_ Albatross Consulting Pty. Ltd. |/ - \ (A.B.N. 75 008 659 498) | /(@) __---_ Tel: (+61) 0500 83 82 81 | _ \ Fax: (+61) 03 5330 3172 | ___ | Http://www.rhyme.com.au |/ \| |---- PGP key available upon request, | / and from pgp5.ai.mit.edu:11371 |/ ---(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] OpenServer 5.0.7: setsockopt(TCP_NODELAY)?
--On Thursday, November 06, 2003 20:19:05 -0500 Tom Lane [EMAIL PROTECTED] wrote: Larry Rosenman [EMAIL PROTECTED] writes: A make check fails at createdb with errors in the postmaster logfile: LOG: setsockopt(TCP_NODELAY) failed: Protocol not available [snip] Better ask them what their problem is with that ... Done, I don't expect an answer till tomorrow. Thanks for the quick diagnosis. LER regards, tom lane -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 972-414-9812 E-Mail: [EMAIL PROTECTED] US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749 pgp0.pgp Description: PGP signature
Re: [HACKERS] pg_stat
Just wondering how often the stats collector resets it self. Is this a parameter i can change? At my knowledge each time that you do an analyze on your db your statistics are changed ( are not incremental I mean), anyway you can set to reset statistics at the start of postgres. I think you're mixed up there. Stats collector is totally different thing. The stats collector is never reset. You can reset it manually by going: select pg_stat_reset(); And you can specify in the postgresql.conf that it should be reset on server restart if you like. Chris ---(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-www] [HACKERS] Changes to Contributor List
On Thursday 06 November 2003 17:18, Peter Eisentraut wrote:
Robert Treat writes:
rant
we don't need links, we need patches
/rant
Let me ask you the questions that people always ask of us:
How does one get involved?
post proposals to pgsql-www and start coding
Where is the code?
http://gborg.postgresql.org/project/pgweb/projdisplay.php
What is the plan?
if you have an itch, scratch it...
Where is the roadmap?
right now andreas' is working on multi-lingual capabilities. i have half an
implementation of variable site width i'd love to finish off, and we have
some pages for things like the release notes that we need to add to the
dynamic site building scripts.
on the advocacy site, there is a file called TODO in the main directory that
has some issues in it that need to be addressed in the current system.
potentially we will also need to add translated press kits and release notes
to the system.
on techdocs there is a todo.php file which is probably completely bogus.
theres some indecision on the direction of this site. I would like to convert
the whole thing to CVS, including the wiki pages that comprised the guides
section. others are testing using bricolage to make a new site at which time
some of the data would be transitioned over. i happen to think there are
several files on this site that should be moved to the main www site, i'd be
happy to expand on that if people start doing work on it. really the most
important thing here is that we get some movement on the site in order to
ditch the old VM the site lives on and get it on our new web VM.
Where can issues be discussed?
[EMAIL PROTECTED]
Who is working on this?
myself, dave page, devrim gunduz, andreas grabmller are the primary folks
doing the work, though there are certainly others involved. [that guy marc
seems to be involved somewhat ;-) ]
How can we help?
never send an email saying you guys should post such and such news item on
the web site. instead submit the news item yourself and we can have it
approved and on the site in much less time. :-)
otherwise it works much like any other open source project, if there is
something specific you want to work on, post a proposal or ask if anyone else
is working on it on the -www list.
let me also say on a personal note that if none of this looks interesting but
there is something else that i am working on that you'd like to get involved
in, drop me a line. that last thing i want to do is to continue to
consolidate work around me, I'd much rather empower others to become regular
contributors.
Robert Treat
--
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL
---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] Experimental ARC implementation
Jan Wieck wrote: It also contains the starting work of the discussed background buffer writer. Thus far, the BufferSync() done at a checkpoint only writes out all dirty blocks in their LRU order and over a configurable time (lazy_checkpoint_time in seconds). But that means at least, while the checkpoint is running the backends should not need to flush dirty buffers as well, since all the candidates they get for replacement are clean. My plan is to create another background process very similar to the checkpointer and to let that run forever basically looping over that BufferSync() with a bool telling that it's the bg_writer. Have you considered having the background writer check the pages it is about to write to see if they can be added to the FSM, thereby reducing the need for vacuum? Seems we would need to add a statistics parameter so pg_autovacuum would know how many tuples the background write added to the freespace map, so it doesn't vacuum a table that doesn't need it. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Experimental ARC implementation
Jan Wieck wrote: If the system is write-bound, the checkpointer will find that many dirty blocks that he has no time to nap and will burst them out as fast as possible anyway. Well, at least that's the theory. PostgreSQL with the non-overwriting storage concept can never have hot-written pages for a long time anyway, can it? They fill up and cool down until vacuum. Another idea on removing sync() --- if we are going to use fsync() on each file during checkpoint (open, fsync, close), seems we could keep a hash of written block dbid/relfilenode pairs and cycle through that on checkpoint. We could keep the hash in shared memory, and dump it to a backing store when it gets full, or just have it exist in buffer writer process memory (so it can grow) and have backends that do their own buffer writes all open a single file in append mode and write the pairs to the file, or something like that, and the checkpoint process can read from there. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
[HACKERS] CVS open for development?
Hey - now that we have a branch, is Bruce going to start committed the pgpatches2 list? Chris ---(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] Experimental ARC implementation
Bruce Momjian [EMAIL PROTECTED] writes: Have you considered having the background writer check the pages it is about to write to see if they can be added to the FSM, thereby reducing the need for vacuum? The 7.4 rewrite of FSM depends on the assumption that all the free space in a given relation is reported to FSM in one batch (ie, at the end of a VACUUM pass). This solves problems in both speed (page-at-a-time update of FSM was horrendously expensive) and space allocation policy (we now use the number of interesting pages in each relation as input information for the allocation policy). To do anything like the above, you'd need to find different solutions to these problems. regards, tom lane ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Experimental ARC implementation
Tom Lane wrote: Bruce Momjian [EMAIL PROTECTED] writes: Have you considered having the background writer check the pages it is about to write to see if they can be added to the FSM, thereby reducing the need for vacuum? The 7.4 rewrite of FSM depends on the assumption that all the free space in a given relation is reported to FSM in one batch (ie, at the end of a VACUUM pass). This solves problems in both speed (page-at-a-time update of FSM was horrendously expensive) and space allocation policy (we now use the number of interesting pages in each relation as input information for the allocation policy). To do anything like the above, you'd need to find different solutions to these problems. Yea, shame. I never liked sequentially scanning a huge table just to find the few free tuples. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] CVS open for development?
Christopher Kings-Lynne wrote: Hey - now that we have a branch, is Bruce going to start committed the pgpatches2 list? Yes, once my email backlog is cleared --- probably early next week. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] postgresql-7.4RC1 - Memory fault(coredump) on HP-UX
Verbus Counts wrote:
{/opt/postgres/postgresql-7.4RC1}$ ll core
-rw--- 1 postgres postgres726684 Nov 6 10:55 core
Can you show us the stack trace ?
Regards
Gaetano Mendola
Here is:
(gdb) backtrace
#0 0xc0198e40 in free+0x130 () from /usr/lib/libc.2
#1 0xc00cca4c in close+0x2e8 () from /usr/lib/libnss_dns.1
#2 0xc00cae60 in _nss_dns_getipnodebyname+0x74()from /usr/lib/libnss_dns.1
#3 0xc01eb878 in nss_search+0x188 () from /usr/lib/libc.2
#4 0xc0161d24 in __getipnodebyname_r+0xa84 () from /usr/lib/libc.2
#5 0xc01611fc in getipnodebyname+0x94 () from /usr/lib/libc.2
#6 0xc01602a0 in getaddrinfo+0x288 () from /usr/lib/libc.2
#7 0x10cd0c in getaddrinfo_all+0x2c ()
#8 0x149e3c in pgstat_init+0xf4 ()
#9 0x146818 in PostmasterMain+0x6bc ()
#10 0x110f2c in main+0x238 ()
--
Reagrds,
Verbus
---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] Experimental ARC implementation
Bruce Momjian [EMAIL PROTECTED] writes: Have you considered having the background writer check the pages it is about to write to see if they can be added to the FSM, thereby reducing the need for vacuum? Seems we would need to add a statistics parameter so pg_autovacuum would know how many tuples the background write added to the freespace map, so it doesn't vacuum a table that doesn't need it. This would suffer from the previously mentioned problem of having to pull in index pages and dirty them when it's trying to flush and clean pages. Conceivably it could just count up the dead tuples and provide that information to something like pg_autovacuum so it knows when it's time to run a vacuum. I don't see that as all that much of a win over the current heuristics. At best it means a big batch update will trigger a vacuum sooner so you don't have to manually run vacuum to avoid overflowing the fsm. -- greg ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [HACKERS] [BUGS] PostgreSQL client has problems when libbind is installed
Was this problem fixed? Can I request the problem report @ FreeBSD to be closed? Thanks, Palle --On torsdag, juni 12, 2003 18.51.18 -0400 Yves R. Crevecoeur [EMAIL PROTECTED] wrote: Don't break BeOS support. A new version of BeOS will be released very soon. http://www.yellowtab.com http://www.yellowtab.com/board/ http://www.yellowtab.com/support/ Regards, Yves - Original Message - From: Tom Lane [EMAIL PROTECTED] To: Palle Girgensohn [EMAIL PROTECTED] Cc: [EMAIL PROTECTED]; Tom Alsberg [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Thursday, June 12, 2003 2:00 PM Subject: Re: [BUGS] PostgreSQL client has problems when libbind is installed Palle Girgensohn [EMAIL PROTECTED] writes: [ linking libbind causes some obscure problems ] http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/47218 Given that we're not supporting BeOS at the moment anyway, I wonder whether we need libbind on any platform. I know linking it causes some minor problems for me on HPUX (I have to take it out if I want to build with profiling...) Comments anyone? 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]) ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html ---(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
[HACKERS] pg_stat
Just wondering how often the stats collector resets it self. Is this a parameter i can change? ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
