[GENERAL] Postgres8 win2k server autovacuum
Hi, is it possibile to use an autovacuum feature on the win32 platform? Or should I write a service application (or use the at service) to run vacuumdb regularly? thank you, -- Csaba Együd --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.799 / Virus Database: 543 - Release Date: 2004.11.19. ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [GENERAL] 3rd RFD: comp.databases.postgresql (was:
[EMAIL PROTECTED] ("Marc G. Fournier") wrote in
news:[EMAIL PROTECTED]:
> On Fri, 3 Dec 2004, Net Virtual Mailing Lists wrote:
>
> this RFD in no way affects the mailing lists, and is in no way an
> 'official PostgreSQL newsgruop' ... the 'official newsgroups' are the
> gated ones under pgsql.* ...
>
I am curious. Where can i learn about these 'official newsgroups'?
I can't find any information about them on www.postgresql.org.
Could it be put up some information of those groups on the websit. And also
information about the new comp.databases.postgresql when(if) it becomes
approved.
I don't remember how i learnt that they existed when i started to use them
(when they was in comp.databases.postgresql.*) and that i had to connect to
news.postgresql.org to read them. I think that i picked it up reading the
mailing list.
--
Rolf Østvik
---(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: [GENERAL] psql connection timeout
Hi Michael, On Dec 2, 2004, at 11:53 PM, Michael Fuhr wrote: Try setting the PGCONNECT_TIMEOUT environment variable: env PGCONNECT_TIMEOUT=5 psql -h bogushost This works great -- thanks very much. I did not see this anywhere in the documentation. Did I miss it or is the source code the only reference point? Best, John DeSoi, Ph.D. http://pgedit.com/ Power Tools for PostgreSQL ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
[GENERAL] Temporary tables and disk activity
Dear Postgresql experts, Looking at vmstat output on my database server I have been suprised to see lots of disk writes going on while it is doing what should be exclusively read-only transactions. I see almost no disk reads as the database concerned is small enough to fit into the OS disk cache. I suspect that it might be something to do with temporary tables. There are a couple of places where I create temporary tables to "optimise" queries by factoring out what would otherwise be duplicate work. The amount of data being written is of the right order of magnitude for this to be the cause. I fear that perhaps Postgresql is flushing these tables to disk, even though they will be dropped before the end of the transaction. Is this a possibility? What issues should I be aware of with temporary tables? Are there any other common causes of lots of disk writes within read-only transactions? Is there any debug output that I can look at to track this down? Thanks in advance for any help that you can offer. Regards, Phil Endecott. ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [GENERAL] psql connection timeout
John DeSoi wrote: > Hi Michael, > > On Dec 2, 2004, at 11:53 PM, Michael Fuhr wrote: > > > Try setting the PGCONNECT_TIMEOUT environment variable: > > > > env PGCONNECT_TIMEOUT=5 psql -h bogushost > > > > > This works great -- thanks very much. > > I did not see this anywhere in the documentation. Did I miss it or is > the source code the only reference point? I see it mentioned in the libpq section of the manual. Those variables actually affect all applications that use libpq, including psql. -- 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 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [GENERAL] 3rd RFD: comp.databases.postgresql
On 12/3/2004 4:12 PM, Mike Cox wrote: Jan Wieck wrote: So how exactly do you think that big number of non-developer advanced PostgreSQL users will populate the comp.* groups? I don't see them there right now, and without them the comp.* groups are the wrong groups because you will not get answers to questions there. Look at this poll. http://scripts.postgresql.org/survey.php?View=1&SurveyID=36 The question is only about _an official newsgroup_. To contradict my statement above, the survey question would have to ask about _an official comp.* group NOT gated to the mailing lists_. And it would also have to point out who already said very clearly that and why they would stay on the mailing lists only. Interpreting this survey result as "a large number of experienced and advanced PostgreSQL users would consider to move to a newsgroup where their questions will not be read by Tom Lane, Stephen Szabo (and many other key players who said NO to this on the mailing list already)" is IMHO a too far strech. Jan -- #==# # It's easier to get forgiveness for being wrong than for being right. # # Let's break this rule - forgive me. # #== [EMAIL PROTECTED] # ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [GENERAL] 3rd RFD: comp.databases.postgresql (was:
On Sat, 4 Dec 2004, Rolf Xstvik wrote:
[EMAIL PROTECTED] ("Marc G. Fournier") wrote in
news:[EMAIL PROTECTED]:
On Fri, 3 Dec 2004, Net Virtual Mailing Lists wrote:
this RFD in no way affects the mailing lists, and is in no way an
'official PostgreSQL newsgruop' ... the 'official newsgroups' are the
gated ones under pgsql.* ...
I am curious. Where can i learn about these 'official newsgroups'?
I can't find any information about them on www.postgresql.org.
http://archives.postgresql.org/pgsql-announce/2004-11/msg00011.php
I'm going to post that once a month so that new ppl know as well, so if
anyone has any revisions they'd like to submit, please do ...
Marc G. Fournier Hub.Org Networking Services (http://www.hub.org)
Email: [EMAIL PROTECTED] Yahoo!: yscrappy ICQ: 7615664
---(end of broadcast)---
TIP 8: explain analyze is your friend
Re: [SOLVED] Re: [GENERAL] initdb error: "could not identify current directory" (or, what have i done now?)
OpenMacNews <[EMAIL PROTECTED]> writes: > on my sys: >% ls -ald /Volumes/data > drwxr-x--x 12 openmac wheel 408 Nov 27 15:25 /Volumes/data/ Ah-hah, yes that's undoubtedly it. > if this *does* turn out to be the case, does it make sense to have the script > check perms up through the physical/path of the cwd and report with a more > specific/desciptive error if they're not at least 555 on the mount > point? I'm not in the business of reimplementing getcwd(); especially not to deal with a problem that will break many other things besides Postgres. I'd suggest filing a bug against whatever tool you used to create /Volumes/data/, suggesting that they adopt a less brain-dead default permissions setting. Execute-only on a mount point is just silly. 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: [GENERAL] 3rd RFD: comp.databases.postgresql (was: comp.databases.postgresql.*)
On 3 Dec 2004 20:34:36 GMT, Woodchuck Bill <[EMAIL PROTECTED]> wrote: >David Harmon <[EMAIL PROTECTED]> wrote in >news:[EMAIL PROTECTED]: > >> On Fri, 3 Dec 2004 00:29:40 + (UTC) in news.groups, Marc G. >> Fournier From: <[EMAIL PROTECTED]> wrote, >>>The pgsql.* hierarchy is a not a private one, it is a public one >>>carried by several of the large usenet servers. >> >> What are the rules for creating new groups in pgsgl.*? >> >> > >Fiat-only by Marc. ;-) I think that the term that is occasionally used is that the hierarchy has a hierarchy czar. That is the most straightforward way to manage a hierarchy. I did not say that it was the best or the worst, only the most straightforward. It doesn't address the question of what happens if the czar disappears, for instance. - - Bob McClenon ---(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: [SOLVED] Re: [GENERAL] initdb error: "could not identify current
hi tom, % ls -ald /Volumes/data drwxr-x--x 12 openmac wheel 408 Nov 27 15:25 /Volumes/data/ Ah-hah, yes that's undoubtedly it. and, since i've cleared that up pgsql is, again, behaving. yay. for posterity's -- and other OSX users' -- sake, that's: for the relevant drives/mounts in /Volumes, you need: perms >= 555 (i use) group should include your pgsql unprivileged user 'default' ownership, i believe, is root:admin for mounts, hence your pgsql user would need to be added as a user to grup:admin if this *does* turn out to be the case, does it make sense to have the script check perms up through the physical/path of the cwd and report with a more specific/desciptive error if they're not at least 555 on the mount point? I'm not in the business of reimplementing getcwd(); especially not to deal with a problem that will break many other things besides Postgres. whoa! i wasn't suggesting that at all ... rather, perhaps, simply a perms check from within the initdb script and an 'informative' error to the end-user. if i were the 1st/only to see such an issue, i'd, of course, not even bother with the suggestion ... but, as we've seen, it's raised its ugly head elsewhere (google: 'getcwd initdb') I'd suggest filing a bug against whatever tool you used to create /Volumes/data/, suggesting that they adopt a less brain-dead default permissions setting. Execute-only on a mount point is just silly. i have a suspicion it has to do with my filesharing/automount system/setup/settings. i'd had a bunch o' headaches a fairly long while back w/ getting Samba, AFS & NFS to play nice together. i'm fairly sure perms were changed, and the mount points may have been (inadvertently?) munged. why is 'suddenly' changed in the last days, i have no flippin' idea as yet! postgresql may have been, simply, the 1st (me <-- surprised) app to 'hit' the getcwd path sensitivity. hence, i think i have to file a bug-report with myself ... =) two points o' feedback: (a) without your help/suggestions, finiding this would've taken me a *lot* longer (thx!), and (b) if this is in the pgsql docs (should it be?), i simply missed, misread or misunderstood it. cheers, richard ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [SOLVED] Re: [GENERAL] initdb error: "could not identify current directory" (or, what have i done now?)
OpenMacNews <[EMAIL PROTECTED]> writes:
> whoa! i wasn't suggesting that at all ... rather, perhaps, simply a perms
> check
> from within the initdb script and an 'informative' error to the
> end-user.
We're doing the best we can already: when the failure occurs, we really
don't know which directory is the problem, and cannot find out because
we can't navigate above it to find out its name.
I note that pwd is not any better:
g42:~ tgl$ mkdir ~/zit
g42:~/zit tgl$ mkdir ~/zit/zap
g42:~/zit tgl$ chmod 111 ~/zit
g42:~/zit tgl$ cd ~/zit/zap
g42:~/zit/zap tgl$ pwd
/Users/tgl/zit/zap
g42:~/zit/zap tgl$ /bin/pwd
pwd: : Permission denied
g42:~/zit/zap tgl$
(bash is probably not doing anyone any favors by masking the problem in
its built-in PWD command.)
There are limited situations where it makes sense to create a directory
that has execute but not read permissions ("drop box" directories being
the main thing I can think of offhand). But it's simply wrong to
create a directory that way without a very specific purpose in mind.
You need to try to reconstruct how /Volumes/data/ got to be that way,
and see if it was simple pilot error or if some tool messed up the
permissions for you.
regards, tom lane
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster
Re: [SOLVED] Re: [GENERAL] initdb error: "could not identify current
tom, We're doing the best we can already: when the failure occurs, we really don't know which directory is the problem, and cannot find out because we can't navigate above it to find out its name. good point. catch-22. at the very least, some knowledgeable commentary in docs/FAQ/howto/Troubleshooting/etc could well be useful ... I note that pwd is not any better: g42:~ tgl$ mkdir ~/zit g42:~/zit tgl$ mkdir ~/zit/zap g42:~/zit tgl$ chmod 111 ~/zit g42:~/zit tgl$ cd ~/zit/zap g42:~/zit/zap tgl$ pwd /Users/tgl/zit/zap g42:~/zit/zap tgl$ /bin/pwd pwd: : Permission denied g42:~/zit/zap tgl$ interesting. i need to read-up/monkey-around a bit b4 it bites me in the a__ again. (bash is probably not doing anyone any favors by masking the problem in its built-in PWD command.) being primarily a tcsh user (yes, i'm old), i did'na kno that. so *that's* the diff bet pwd and /bin/pwd on _your_ sys, yes? You need to try to reconstruct how /Volumes/data/ got to be that way, and see if it was simple pilot error or if some tool messed up the permissions for you. of course, you're right. i'm betting on occam's razor --> 'pilot error' (hence, the "(or, what have i done now?)" in the Sub:), but due diligence _is_ called for. (there's a cute/useful mount manager util called SharePoints which i tried a while back that i _think_ may have made it EASY for me to screw things up ... not their fault, tho) again, tom, thanks! now on to make postfix behave w/ pgsql8rc1! =) best, richard ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
Re: [GENERAL] [ANNOUNCE] PostgreSQL 8.0.0 Release Candidate 1
On Sat, Dec 04, 2004 at 12:18:03AM -0400, Marc G. Fournier wrote: > > After 3 months of BETA testing, The PostgreSQL Global Development Group is > pleased to announce that we've locked down the source code and have now > released our first Release Candidate. > > Our goal is to formally release 8.0.0 around the 15th of December, and to > ensure that we are as bug free as possible, on as many platforms as > possible, we are asking everyone that can to test and report both > successes, and failures, on the various operating systems and platforms. > > For a complete list of changes/improvement since Beta 5 was released, > please see: > >ftp://ftp.postgresql.org/pub/source/v8.0.0beta/ChangeLog-Beta5-to-RC1 > > That said, Release Candidate 1 is currently available for download on all > mirrors: > > http://www.postgresql.org/mirrors-ftp.html > > As with all releases, the success of this release falls in the your hands > ... in order to release as stable and reliable of a server as is possible, > we need as many people out there to put it through her paces as possible, > on as many platforms as possible. We urge anyone, and everyone, to > download a copy and run her through her regression tests, and report > any/all problems, and bugs, to > > [EMAIL PROTECTED] > > Once more, on behalf of all of the developers, Happy Bug Hunting ... It's also on http://bt.postgresql.org/ :) Cheers, D -- David Fetter [EMAIL PROTECTED] http://fetter.org/ phone: +1 510 893 6100 mobile: +1 415 235 3778 Remember to vote! ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
[GENERAL] How can I expand serialized BLOBs into pseudo columns
I have a table (quite a few of them actually) where python objects are
serialized into a column. So a table might look like:
CREATE TABLE mytable (id int, obj bytea);
When I'm trying to diagnose/debug things, I'd like to be able to expand
the 'obj' column into multiple columns in a view. I created a type and
wrote a plpgsql function that expands the object. i.e.:
CREATE TYPE myitem AS (val1 text, val2 text);
CREATE FUNCTION expandobj(bytea) returns myitem as '...' LANGUAGE
plpgsql;
Then I tried:
SELECT expandobj(obj), * from mytable;
I get:
ERROR: cannot display a value of type record
I think/hope I'm missing something pretty stupid, but I can't figure
out what it might be. Any help would be appreciated. There might even
be a quite better way.
Eric.
Here's a script to reproduce the problem:
CREATE TABLE mytable (id int, obj text);
INSERT INTO mytable VALUES (1, 'x,y');
CREATE TYPE myitem AS (val1 text, val2 text);
CREATE or REPLACE FUNCTION expandobj(text) returns myitem as '
DECLARE
items text[];
item myitem%rowtype;
BEGIN
items := string_to_array($1, '','');
item.val1 := items[1];
item.val2 := items[2];
return item;
END
' LANGUAGE 'plpgsql';
SELECT * from expandobj('a,b'); -- this works
SELECT expandobj(obj), * from mytable; -- this does not
-- I'd like to see four columns: val1, val2, id, obj
---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
[GENERAL] Posgres8 beta5 on WinXP won't start
Hi, Before anything I'm very sorry for sending that "RTFM" style question about pg_autovacuum. I found it, but I couldn't try it out... I faced a problem starting the postgres service. After installation everything had gone well until I started pg_autovacuum.exe. I do not think that something is wrong with pg_autovacuum but the fact is that that was the point Postgres stopped starting. I restarted the comupter but nothing changed. I unregistered the service and reregistered. No success. After that I switched user to postgres on my XP box and started the server successfuly from the commanline (pg_ctl start -d "..."). Oh luck - I immediatelly dumped out everything. So the problem is something around the usernames or the priviliges. Where do I search the problem? What could go wrong? And how??? Is it possible that pg_vacuum sets any priviliges silently?? Don't think so. Many thanks -- Csaba Együd --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.805 / Virus Database: 547 - Release Date: 2004.12.03. ---(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: [GENERAL] reclaiming diskspace bloat w/near-zero downtime
On Saturday December 4 2004 1:01, Ed L. wrote: > > ...I have a > shell game using rules that goes like this for bloated table foo: > ... > begin > drop view foo > alter table slim_foo rename to foo > commit > > Some basic testing for my particulars suggests this works, but anyone see > any issues with this? I guess this is not safe in 7.3.4. :( Dropping the view within a transaction causes the following error if a triggered function is concurrently accessing that view: WARNING: Error occurred while executing PL/pgSQL function f WARNING: line 16 at SQL statement ERROR: RelationClearRelation: relation 7372083 deleted while still in use Ed ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
[GENERAL] List archives search function broken
Using the list archive search function currently fails with 503 Service Unavailable. Should messages about list archive problems go to pgsql-general, or would it be better to use one of the other lists like bugs, hackers, or www? -- Michael Fuhr http://www.fuhr.org/~mfuhr/ ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [GENERAL] How can I expand serialized BLOBs into pseudo columns
Eric Brown wrote: SELECT expandobj(obj), * from mytable; I get: ERROR: cannot display a value of type record I think/hope I'm missing something pretty stupid, but I can't figure out what it might be. Any help would be appreciated. There might even be a quite better way. What you're trying to do isn't supported in 7.4 and earlier. Works in 8.0.0 (which just went RC1) though: regression=# SELECT expandobj(obj), * from mytable; -- this does not expandobj | id | obj ---++- (x,y) | 1 | x,y (1 row) and so does: regression=# SELECT (expandobj(obj)).val1, (expandobj(obj)).val2, * from mytable; val1 | val2 | id | obj --+--++- x| y| 1 | x,y (1 row) HTH, Joe ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
[GENERAL] Trigger problem
Hi all I'm having a problem with PostgreSQL 7.4.6-2 I do: drop table t1; drop table t2; create table t1 (id integer); create table t2 (id integer); CREATE OR REPLACE FUNCTION myfunc() RETURNS trigger AS ' BEGIN insert into t2 values(NEW.id); END; ' LANGUAGE plpgsql; CREATE TRIGGER mytri AFTER INSERT ON t1 FOR EACH STATEMENT EXECUTE PROCEDURE myfunc(); insert into t1 values(1); and I get: ERROR: record "new" is not assigned yet DETAIL: The tuple structure of a not-yet-assigned record is indeterminate. CONTEXT: PL/pgSQL function "myfunc" line 2 at SQL statement Thanks for you help! -- Henry Molina R&D CMN Consulting ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [GENERAL] Trigger problem
On Sat, Dec 04, 2004 at 11:53:46PM -0500, Henry Molina wrote: > drop table t1; > drop table t2; > create table t1 (id integer); > create table t2 (id integer); > CREATE OR REPLACE FUNCTION myfunc() RETURNS trigger AS ' > BEGIN > insert into t2 values(NEW.id); > END; > ' LANGUAGE plpgsql; > > CREATE TRIGGER > mytri > AFTER INSERT ON t1 FOR EACH STATEMENT > EXECUTE PROCEDURE myfunc(); > insert into t1 values(1); > > and I get: > > ERROR: record "new" is not assigned yet > DETAIL: The tuple structure of a not-yet-assigned record is > indeterminate. > CONTEXT: PL/pgSQL function "myfunc" line 2 at SQL statement If you want to access NEW then declare your trigger to be FOR EACH ROW. Statement-level triggers set NEW to NULL because the trigger fires not for a particular row, but for the entire statement, which could affect multiple rows. Also, your trigger function doesn't return a value. Even though AFTER triggers ignore the return value, the function must still return something. The documentation recommends returning NULL when the value will be ignored. -- Michael Fuhr http://www.fuhr.org/~mfuhr/ ---(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: [GENERAL] Trigger problem
On Sat, 4 Dec 2004, Henry Molina wrote: > drop table t1; > drop table t2; > create table t1 (id integer); > create table t2 (id integer); > CREATE OR REPLACE FUNCTION myfunc() RETURNS trigger AS ' > BEGIN > insert into t2 values(NEW.id); > END; > ' LANGUAGE plpgsql; > > CREATE TRIGGER > mytri > AFTER INSERT ON t1 FOR EACH STATEMENT > EXECUTE PROCEDURE myfunc(); > insert into t1 values(1); Currently statement triggers don't have any way to get at the affected rowset. A FOR EACH ROW trigger should work for a case like the above, although I think you'll need to add a return statement to the function as well. ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
[GENERAL] Select distinct sorting all rows 8.0rc1
System is 4-way Opteron 844, 16 GB memory, SCSI. This is a trial run for converting an Oracle DB, so system is not optimized. I have shared_buffers = 5 work_mem = 65536 A table has about 65 million rows (data collection system.) It has a primary key, no other indexes, no OIDs. The primary key contains 5 columns, of which service_id is the first (i.e., higher order.) I've run a simple ANALYZE on this table. Trying to find the unique service_id values, I did the following. If I'm reading this right, the sequential scan is passing all 65 million retrieved values onto the sort, which understandably takes a long time. This query won't be run very often, if ever, in production, so I don't want to add additional indexes to support it. Our known queries run very fast, about 1.2 seconds the first time through, and 20 msecs on repeats. Can I run ANALYZE in a different way so that queries like this can be completed in a shorter amount of time? I'm trying to anticipate ad-hoc queries the user community might come up with. Since there are such a small number or result rows compared to the number of total rows, perhaps using a hash table to record unique values would avoid passing all 65 million rows to the sort. Thanks for all suggestions. estat=> explain analyze select distinct(service_id) from five_min_stats_200408; QUERY PLAN Unique (cost=13578354.70..13894902.76 rows=726 width=12) (actual time=1227906.271..1282110.055 rows=879 loops=1) -> Sort (cost=13578354.70..13736628.73 rows=63309612 width=12) (actual time=1227906.266..1255961.318 rows=63359396 loops=1) Sort Key: service_id -> Seq Scan on five_min_stats_200408 (cost=0.00..1668170.12 rows=63309612 width=12) (actual time=0.061..80398.222 rows=63359396 loops=1) Total runtime: 1284212.556 ms (5 rows) Time: 1284213.359 ms -- Guy Rouillier ---(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
[GENERAL] Preview of Fourth PostgreSQL RFD.
The following is a preview of the 4th PostgreSQL RFD. Please suggest any changes or improvements. I will send it to the NAN team Sunday night. It can take up to a week to be posted by the NAN team, so I'll try to get the bugs out of the RFD before I give it to them. :-) P.S. feel free to post a patch so I can just patch the RFD if everyone likes your changes. ;-) REQUEST FOR DISCUSSION (RFD) unmoderated group comp.databases.postgresql This is a formal Request For Discussion (RFD) for the creation of the worldwide unmoderated Usenet newsgroup comp.databases.postgresql. This is not a Call for Votes (CFV); you cannot vote at this time. Procedural details are below. CHANGES: The changes from the previous RFD are: 1. Changed the term "private hierarchy" to "public pgsql.* hierarchy" in the rational to describe the pgsql.* usenet PostgreSQL hierarchy. 2. Added Security topics to the charter. 3. Added Scalability topics to the charter. 4. Added permission to post a weekly Official FAQ that includes information about the mailing lists, pgsql.* hierarchies, PostgreSQL IRC. A bot is allowed to post the Official FAQ. 5. Re-Organized the Charter to make it easier to read with more headings. RATIONALE: comp.databases.postgresql To provide a Big Eight newsgroup for users of the PostgreSQL Relational Database Management System. Currently there are mailing lists gated to the public pgsql.* hierarchy. Issues with mailing list gateways, and the much larger distribution of the Big Eight hierarchy make it extremely desirable to have a PostgreSQL group in the Big Eight. CHARTER: comp.databases.postgresql The newsgroup comp.databases.postgresql is a Big Eight Usenet discussion group for the PostgreSQL Relational Database Management System. Topics of discussion may include: ADMINISTRATION *Discussions pertaining to the administration, compilation and installation of PostgreSQL. *Announcements of new versions of PostgreSQL, PostgreSQL related software, and documentation. *Administration of PostgreSQL interfaces, including JDBC and ODBC. *Administration and installation of the Contrib packages. *Point in Time Recovery, backups. *Startup scripts, or scripts that automate PostgreSQL related tasks. DEVELOPING WITH POSTGRESQL *Programming using PostgreSQL. Stored Procedures, Server-Side functions written in C, PL/pgSQL,PL/Perl, and other languages. *Developing with PostgreSQL interfaces, including JDBC and ODBC. GENERAL *General discussions of PostgreSQL. *PostgreSQL Promotional ideas, etc. *Assisting beginners in using the PostgreSQL Relational Database Management system. Help answer basic questions. *Discussions of the Contrib packages. SCALABLITY *PostgreSQL performance, benchmarking and related topics. *Replication *Hardware, Software configurations and recommendations for optimal PostgreSQL operation. Examples are x86-64, Non Uniform Memory Access, etc. SECURITY *Announcements of patches that fix vulnerabilities. Bug reports and PostgreSQL core development should be directed to the mailing lists that deal with those topics. *Best practices to design and keep PostgreSQL secure. *SSH, SSL, the Crypto Contrib packages, and other security topics. SQL *Normalization and theory as it applies to PostgreSQL. *Transactions, Indices, Cursors, Triggers, and Nested Transactions. *PostgreSQL specific topics such as Objects. *Help with SQL. An Official Weekly FAQ may be posted that includes information about the mailing lists, pgsql.* hierarchies, PostgreSQL IRC. A bot is allowed to post the Official FAQ. Posting of binaries is not permitted, with the exception of digital signatures such as PGP. Core PostgreSQL development, bug reports, are off-topic in comp.databases.postgresql. Those topics are to be discussed in pgsql.* or the PostgreSQL mailing lists. END CHARTER. PROCEDURE: This is a request for discussion, not a call for votes. In this phase of the process, any potential problems with the proposed newsgroups should be raised and resolved. The discussion period will continue for a minimum of 21 days (starting from when the first RFD for this proposal is posted to news.announce.newgroups), after which a Call For Votes (CFV) may be posted by a neutral vote taker if the discussion warrants it. Please do not attempt to vote until this happens. All discussion of this proposal should be posted to news.groups. This RFD attempts to comply fully with the Usenet newsgroup creation guidelines outlined in "How to Create a New Usenet Newsgroup" and "How to Format and Submit a New Group Proposal." Please refer to these documents (available in news.announce.newgroups) if you have any questions about the process. DISTRIBUTION: This RFD has been posted to the following newsgroups: news.announce.newgroups, news.groups, comp.databases, comp.unix.bsd.freebsd.misc, pgsql.general Proponent: Mike Cox <[EMAIL PROTECTED]> ---(end of broadcast)
Re: [GENERAL] List archives search function broken
fixed > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Michael Fuhr > Sent: Sunday, December 05, 2004 9:41 AM > To: [EMAIL PROTECTED] > Subject: [GENERAL] List archives search function broken > > Using the list archive search function currently fails with > 503 Service Unavailable. > > Should messages about list archive problems go to > pgsql-general, or would it be better to use one of the other > lists like bugs, hackers, or www? > > -- > Michael Fuhr > http://www.fuhr.org/~mfuhr/ > > ---(end of > broadcast)--- > TIP 7: don't forget to increase your free space map settings > > ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
