Re: [HACKERS] Giving up multiple postmaster + RPM issue
On Sat, Nov 11, 2006 at 05:56:03PM +0200, Devrim GUNDUZ wrote: Hello, As some of you already know, I have been working on multiple postmaster + RPM issue for some time. We are approaching 8.2.0, and I still could not complete this. Also, I'm having problems with my eyes which prevents me working (for long hours) (Vision Fatigue); so I want to give up this issue at least for now. I will create a new branch for this; and use the old spec file format for 8.2. Here is the spec file that I plan to use for 8.2: http://cvs.pgfoundry.org/cgi-bin/cvsweb.cgi/pgsqlrpms/specs/8.2/postgresql-8.2.spec?rev=1.8content-type=text/x-cvsweb-markup Revisions greater then 1.8 are prototypes for multiple postmaster issue, so should not be used for 8.2 final. I *hope* to release 8.2 SRPM next week so that people will test it. I tried to implement the same type of thing with other RPM packages. Having multiple versioned RPMs installed is not so easy. Most of the tools like yum assume you want to upgrade, not install new versions thus you get lots of problems. (You can designate packages install-only in yum.conf, but then you have to be sure that everything works...) My solution was to create RPMs with the version number embedded in the name. Thus for 7.4.13 and 8.1.5 I have: postgres7.4-13-1_fc6.x86_64.rpm postgres8.1-5-1_fc6.x86_64.rpm Everything goes into /usr/local/pg7.4 and /usr/local/pg8.1, init scripts are /etc/init.d/postgres8.1, /etc/init.d/postgres7.4 That combined with some 'alternatives' magic makes things work well for the hosts at my current job. spec file(s) available on request... -- Paul Lindner| | | | | | | | | | [EMAIL PROTECTED] pgpaOCeidFNHF.pgp Description: PGP signature
Re: [HACKERS] Giving up multiple postmaster + RPM issue
On Sun, Nov 12, 2006 at 01:27:26AM -0800, Paul Lindner wrote: My solution was to create RPMs with the version number embedded in the name. Thus for 7.4.13 and 8.1.5 I have: postgres7.4-13-1_fc6.x86_64.rpm postgres8.1-5-1_fc6.x86_64.rpm Everything goes into /usr/local/pg7.4 and /usr/local/pg8.1, init scripts are /etc/init.d/postgres8.1, /etc/init.d/postgres7.4 That's the apporaich the debian packages take too, although they also add a layer so you can have multiple clusters also, each with whatever version you like. Have a ncie day, -- Martijn van Oosterhout kleptog@svana.org http://svana.org/kleptog/ From each according to his ability. To each according to his ability to litigate. signature.asc Description: Digital signature
Re: [HACKERS] [PATCHES] WIP 2 interpreters for plperl
[moving to -hackers] I wrote: I have made some progress with what I think is needed to have two interpreters for plperl. This is a lot harder than the pltcl case for two reasons: 1. there are no restrictions on having 2 tcl interpreters, and 2. tcl does not need to save and restore context as we have to do with perl. I think I have a conceptual siolution to these two problems, but what I have is currently segfaulting somewhat myteriously. Tracing a dynamically loaded library in a postgres backend with a debugger is less than fun, too. I am attaching what I currently have, liberally sprinkled with elog(NOTICE) calls as trace writes. With a little more perseverance I found the problem. The attached patch passes regression. But it now needs plenty of eyeballs and testing. Well, if anyone cast eyeballs over it they kept it secret from me :-( However, I have now tested the patch with the little script shown below and it seems to do the Right Thing (tm) in switching context and restoring it. So I think it can be applied to HEAD, along with an addition to the docs and a release note. Since this is a behaviour modification, do we want to apply it to the back branches? Doing so would certainly be possible, although it would be non-trivial. cheers andrew drop function if exists f1(int); drop function if exists f2(int); create function f1(int) returns void language plperl as $$ my $arg = shift; elog NOTICE,in plperl func f1($arg); return if ($arg 5); $arg++; spi_exec_query(select f2($arg)); $$; create function f2(int) returns void language plperlu as $$ my $arg = shift; elog NOTICE,in plperlu func f2($arg); return if ($arg 5); $arg++; spi_exec_query(select f1($arg)); $$; select f1(0); select f2(0); ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
Re: [HACKERS] Frequent Update Project: Design Overview of HOTUpdates
On Friday 10 November 2006 08:53, Simon Riggs wrote:
On Fri, 2006-11-10 at 12:32 +0100, Zeugswetter Andreas ADI SD wrote:
4. although at first it might seem so I see no advantage for vacuum with
overflow
No need to VACUUM the indexes, which is the most expensive part. The
more indexes you have, the more VACUUM costs, not so with HOT.
This isn't exactly true though right? Since the more indexes you have, the
more likely it is that your updating an indexed column, which means HOT isn't
going to work for you. One common use case that seems problematic is the
indexed, frequently updated timestamp field.
--
Robert Treat
Build A Brighter LAMP :: Linux Apache {middleware} PostgreSQL
---(end of broadcast)---
TIP 4: Have you searched our list archives?
http://archives.postgresql.org
[HACKERS] error compiling 8.2 in debian sarge
Hi... i'm using debian sarge and when trying to compile 8.2beta3 got this fail... gcc -O2 -Wall -Wmissing-prototypes -Wpointer-arith -Winline -Wendif-labels -fno-strict-aliasing -g -Wno-error -L../../../../src/port -Wl,-rpath,'/usr/local/pgsql/pgsql/lib' preproc.o type.o ecpg.o ecpg_keywords.o output.o keywords.o c_keywords.o ../ecpglib/typename.o descriptor.o variable.o -lpgport -lz -lreadline -lcrypt -ldl -lm -o ecpg /usr/lib/libc_nonshared.a(elf-init.oS)(.text.__i686.get_pc_thunk.bx+0x0): In function `__i686.get_pc_thunk.bx': : multiple definition of `__i686.get_pc_thunk.bx' ../ecpglib/typename.o(.gnu.linkonce.t.__i686.get_pc_thunk.bx+0x0):/home/postgres/PG_RELEASES/pgsql-8.2beta2/src/interfaces/ecpg/ecpglib/typename.c:18: first defined here collect2: ld returned 1 exit status make[4]: *** [ecpg] Error 1 make[4]: Leaving directory `/home/postgres/PG_RELEASES/pgsql-8.2beta2/src/interfaces/ecpg/preproc' a bug or my fault (maybe some lib missing)? -- regards, Jaime Casanova Programming today is a race between software engineers striving to build bigger and better idiot-proof programs and the universe trying to produce bigger and better idiots. So far, the universe is winning. Richard Cook ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] Giving up multiple postmaster + RPM issue
Hi, On Sun, 2006-11-12 at 01:27 -0800, Paul Lindner wrote: Everything goes into /usr/local/pg7.4 and /usr/local/pg8.1, init scripts are /etc/init.d/postgres8.1, /etc/init.d/postgres7.4 /usr/local is not the right place for a database server, per Linux FSH. spec file(s) available on request. I'll be happy if you send me the spec. Regards, -- The PostgreSQL Company - Command Prompt, Inc. 1.503.667.4564 PostgreSQL Replication, Consulting, Custom Development, 24x7 support Managed Services, Shared and Dedicated Hosting Co-Authors: plPHP, plPerlNG - http://www.commandprompt.com/ signature.asc Description: This is a digitally signed message part
Re: [HACKERS] error compiling 8.2 in debian sarge
i'm using debian sarge and when trying to compile 8.2beta3 got this fail... Just checked: no problems here on a stock 3.1. What ./configure switches did you use? Bye, Chris. ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] error compiling 8.2 in debian sarge
On Sun, Nov 12, 2006 at 02:31:24PM -0500, Jaime Casanova wrote: Hi... i'm using debian sarge and when trying to compile 8.2beta3 got this fail... snip /usr/lib/libc_nonshared.a(elf-init.oS)(.text.__i686.get_pc_thunk.bx+0x0): In function `__i686.get_pc_thunk.bx': : multiple definition of `__i686.get_pc_thunk.bx' ../ecpglib/typename.o(.gnu.linkonce.t.__i686.get_pc_thunk.bx+0x0):/home/postgres/PG_RELEASES/pgsql-8.2beta2/src/interfaces/ecpg/ecpglib/typename.c:18: first defined here collect2: ld returned 1 exit status I had that error once and it was caused by a dodgy version of the C compiler, or it was installed incorrectly, so that part of the project was built with one version and part with another. Make sure you've got the C compiler correctly installed and that everything is being compiled/linked with the same version. Have a ncie day, -- Martijn van Oosterhout kleptog@svana.org http://svana.org/kleptog/ From each according to his ability. To each according to his ability to litigate. signature.asc Description: Digital signature
Re: [HACKERS] error compiling 8.2 in debian sarge
On 11/12/06, Chris Mair [EMAIL PROTECTED] wrote: i'm using debian sarge and when trying to compile 8.2beta3 got this fail... Just checked: no problems here on a stock 3.1. What ./configure switches did you use? ./configure --prefix=/usr/local/pgsql/pgsql --enable-debug--enable-cassert --enable-depend -- regards, Jaime Casanova Programming today is a race between software engineers striving to build bigger and better idiot-proof programs and the universe trying to produce bigger and better idiots. So far, the universe is winning. Richard Cook ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] error compiling 8.2 in debian sarge
On 11/12/06, Martijn van Oosterhout kleptog@svana.org wrote: On Sun, Nov 12, 2006 at 02:31:24PM -0500, Jaime Casanova wrote: Hi... i'm using debian sarge and when trying to compile 8.2beta3 got this fail... snip /usr/lib/libc_nonshared.a(elf-init.oS)(.text.__i686.get_pc_thunk.bx+0x0): In function `__i686.get_pc_thunk.bx': : multiple definition of `__i686.get_pc_thunk.bx' ../ecpglib/typename.o(.gnu.linkonce.t.__i686.get_pc_thunk.bx+0x0):/home/postgres/PG_RELEASES/pgsql-8.2beta2/src/interfaces/ecpg/ecpglib/typename.c:18: first defined here collect2: ld returned 1 exit status I had that error once and it was caused by a dodgy version of the C compiler, or it was installed incorrectly, so that part of the project was built with one version and part with another. Make sure you've got the C compiler correctly installed and that everything is being compiled/linked with the same version. gcc (GCC) 3.3.5 (Debian 1:3.3.5-13) i haven't upgraded it lately, at least not by myself. any idea how to know if is that? -- regards, Jaime Casanova Programming today is a race between software engineers striving to build bigger and better idiot-proof programs and the universe trying to produce bigger and better idiots. So far, the universe is winning. Richard Cook ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] error compiling 8.2 in debian sarge
On Sun, Nov 12, 2006 at 04:06:03PM -0500, Jaime Casanova wrote: /usr/lib/libc_nonshared.a(elf-init.oS)(.text.__i686.get_pc_thunk.bx+0x0): In function `__i686.get_pc_thunk.bx': : multiple definition of `__i686.get_pc_thunk.bx' I had that error once and it was caused by a dodgy version of the C compiler, or it was installed incorrectly, so that part of the project was built with one version and part with another. Make sure you've got the C compiler correctly installed and that everything is being compiled/linked with the same version. gcc (GCC) 3.3.5 (Debian 1:3.3.5-13) i haven't upgraded it lately, at least not by myself. any idea how to know if is that? How many versions of GCC do you have installed? Do the versions of 'gcc -V', 'ld -V' all match? Given the versions numbers, when you run dpkg -l 'gcc*' is that version properly installed? How about versions of g++? When I had that problem I uninstalled all old versions of gcc/g++, did a make clean and recompiled from scratch and that fixed it. I also upgraded glibc to the same date as gcc, since the error is based (I think) on a mismatch between the expectations of the compiler and of the C library. Hope this helps, -- Martijn van Oosterhout kleptog@svana.org http://svana.org/kleptog/ From each according to his ability. To each according to his ability to litigate. signature.asc Description: Digital signature
Re: [HACKERS] error compiling 8.2 in debian sarge
On 11/12/06, Martijn van Oosterhout kleptog@svana.org wrote: On Sun, Nov 12, 2006 at 04:06:03PM -0500, Jaime Casanova wrote: /usr/lib/libc_nonshared.a(elf-init.oS)(.text.__i686.get_pc_thunk.bx+0x0): In function `__i686.get_pc_thunk.bx': : multiple definition of `__i686.get_pc_thunk.bx' I had that error once and it was caused by a dodgy version of the C compiler, or it was installed incorrectly, so that part of the project was built with one version and part with another. Make sure you've got the C compiler correctly installed and that everything is being compiled/linked with the same version. gcc (GCC) 3.3.5 (Debian 1:3.3.5-13) i haven't upgraded it lately, at least not by myself. any idea how to know if is that? How many versions of GCC do you have installed? Do the versions of 'gcc -V', 'ld -V' all match? Given the versions numbers, when you run dpkg -l 'gcc*' is that version properly installed? How about versions of g++? When I had that problem I uninstalled all old versions of gcc/g++, did a make clean and recompiled from scratch and that fixed it. I also upgraded glibc to the same date as gcc, since the error is based (I think) on a mismatch between the expectations of the compiler and of the C library. the problem should be there (i tried to compile 8.1 and failed the same) i will have to fix all this version problem... thanks -- regards, Jaime Casanova Programming today is a race between software engineers striving to build bigger and better idiot-proof programs and the universe trying to produce bigger and better idiots. So far, the universe is winning. Richard Cook ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] [JDBC] server process (PID 1188) exited with exit code
Tom Lane wrote:
Dave Cramer [EMAIL PROTECTED] writes:
This is a server bug, I will post to hackers for you, it has little
to do with JDBC, however the ? can't be a column in a prepared statement
I cannot reproduce any problem using what I think is equivalent in libpq:
I thought we got this one sorted out already, it was a server bug fixed
in beta2? At the time you said:
JEAN-PIERRE PELLETIER [EMAIL PROTECTED] writes:
08:47:19.296 (1) FE= Parse(stmt=null,query=select $1 from (select * from
pg_database) t,oids={23})
Actually, now that I look closely, this command is almost certainly
triggering this beta1 bug:
http://archives.postgresql.org/pgsql-committers/2006-10/msg00107.php
Please try beta2 and see if it isn't fixed.
regards, tom lane
(and the problem went away in beta2)
-O
---(end of broadcast)---
TIP 1: 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] Frequent Update Project: Design Overview ofHOTUpdates
On Sun, 2006-11-12 at 13:01 -0500, Robert Treat wrote: On Friday 10 November 2006 08:53, Simon Riggs wrote: On Fri, 2006-11-10 at 12:32 +0100, Zeugswetter Andreas ADI SD wrote: 4. although at first it might seem so I see no advantage for vacuum with overflow No need to VACUUM the indexes, which is the most expensive part. The more indexes you have, the more VACUUM costs, not so with HOT. This isn't exactly true though right? The above statement is completely true; please don't say I aim to mislead. I've been clear about the pre-conditions for the optimization. This is a straight-up attempt to improve some important use cases. Since the more indexes you have, the more likely it is that your updating an indexed column, which means HOT isn't going to work for you. Well its not a chance thing is it? It's clear that the pre-conditions could in some circumstances be an annoyance, but that in itself isn't an argument against it. I'm especially keen to hear of an optimisation that would work in all cases for heavy updates. (It was I that originally suggested the fillfactor approach to optimising UPDATEs, but regret that although it applies no matter how many indexes you have its not very effective and even that reduces after the first batch of UPDATEs have happened). One common use case that seems problematic is the indexed, frequently updated timestamp field. Not sure of the use case for that? I understand using a timestamp field for optimistic locking; why would you index that rather than the PK? Locating things via coordinates was a use-case that would be non-HOT, are you thinking of something similar? It's important to understand which types of things HOT would optimize/not. HOT probably would change the way you design if you need such a thing. Rather than indexing the co-ordinate you'd end up binning the values so the index value would change less often, so most would be HOT with a few non-HOT UPDATEs. Maybe the same would be true with the timestamp, I'm not sure. -- Simon Riggs EnterpriseDB http://www.enterprisedb.com ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] error compiling 8.2 in debian sarge
i'm using debian sarge and when trying to compile 8.2beta3 got this fail... Just checked: no problems here on a stock 3.1. What ./configure switches did you use? ./configure --prefix=/usr/local/pgsql/pgsql --enable-debug--enable-cassert --enable-depend Again, no problem here. Some version infos are below. Bye, Chris. [EMAIL PROTECTED]:~$ uname -a Linux guest05 2.4.27-3-386 #1 Mon May 29 23:50:41 UTC 2006 i686 GNU/Linux [EMAIL PROTECTED]:~$ gcc --version gcc (GCC) 3.3.5 (Debian 1:3.3.5-13) Copyright (C) 2003 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. [EMAIL PROTECTED]:~$ ld --version GNU ld version 2.15 Copyright 2002 Free Software Foundation, Inc. This program is free software; you may redistribute it under the terms of the GNU General Public License. This program has absolutely no warranty. [EMAIL PROTECTED]:~$ dpkg -l | grep gcc ii gcc3.3.5-3The GNU C compiler ii gcc-3.33.3.5-13 The GNU C compiler ii gcc-3.3-base 3.3.5-13 The GNU Compiler Collection (base package) ii gcc-3.4-base 3.4.3-13sarge1 The GNU Compiler Collection (base package) ii libgcc13.4.3-13sarge1 GCC support library ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
Re: [HACKERS] error compiling 8.2 in debian sarge
On Sun, Nov 12, 2006 at 10:31:17PM +0100, Chris Mair wrote: Again, no problem here. Some version infos are below. Ok, here's a long shot: the error involves /usr/lib/libc_nonshared.a which is supplied by libc6-dev. Does the dev package you have match the actual C library. (bit hard to see how it couldn't, but maybe...). Another tack: http://gcc.gnu.org/ml/gcc/2004-09/msg01528.html suggests an out-of-date binutils as the cause. This suggests a non-clean target build directory. http://gcc.gnu.org/ml/gcc/2004-09/msg01539.html And this debian bug report: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=351629 Google around, many people have run into this and not nailed down the problem. At the very least it appears gcc 3.3 is most susceptable. Are you using straight Debian Stable or a partially upgraded system? Maybe a full upgrade would help. Have a ncie day, -- Martijn van Oosterhout kleptog@svana.org http://svana.org/kleptog/ From each according to his ability. To each according to his ability to litigate. signature.asc Description: Digital signature
Re: [HACKERS] Frequent Update Project: Design Overview ofHOTUpdates
On Sunday 12 November 2006 16:23, Simon Riggs wrote:
On Sun, 2006-11-12 at 13:01 -0500, Robert Treat wrote:
On Friday 10 November 2006 08:53, Simon Riggs wrote:
On Fri, 2006-11-10 at 12:32 +0100, Zeugswetter Andreas ADI SD wrote:
4. although at first it might seem so I see no advantage for vacuum
with overflow
No need to VACUUM the indexes, which is the most expensive part. The
more indexes you have, the more VACUUM costs, not so with HOT.
This isn't exactly true though right?
The above statement is completely true; please don't say I aim to
mislead. I've been clear about the pre-conditions for the optimization.
This is a straight-up attempt to improve some important use cases.
I don't think you were trying to mislead, just my interpretation of the scheme
requires a qualifier for that statement, namely that you are not updating an
indexed column. Your statements above didn't include that qualfier, so I just
wanted to make sure I wasn't overlooking something. Actually I think I was,
for example if your not updating all of the indexes on a table (which isn't
likely) you're going to be better off with HOT, but in any case my apologies
if I worded it badly.
Since the more indexes you have, the
more likely it is that your updating an indexed column, which means HOT
isn't going to work for you.
Well its not a chance thing is it? It's clear that the pre-conditions
could in some circumstances be an annoyance, but that in itself isn't an
argument against it. I'm especially keen to hear of an optimisation that
would work in all cases for heavy updates. (It was I that originally
suggested the fillfactor approach to optimising UPDATEs, but regret that
although it applies no matter how many indexes you have its not very
effective and even that reduces after the first batch of UPDATEs have
happened).
I'd be keen to tell you such a plan if I had one, but obviously it isn't an
easy problem to solve. :-)
One common use case that seems problematic is the
indexed, frequently updated timestamp field.
Not sure of the use case for that? I understand using a timestamp field
for optimistic locking; why would you index that rather than the PK?
Let's say you are doing system monitoring and you are updating last contact
times fairly regularly. Sometimes you need to look at specific systems (the
pk) and sometimes you need to query based on a time range (the indexed time
field).
--
Robert Treat
Build A Brighter LAMP :: Linux Apache {middleware} PostgreSQL
---(end of broadcast)---
TIP 7: You can help support the PostgreSQL project by donating at
http://www.postgresql.org/about/donate
Re: [HACKERS] adminpack and pg_catalog
On Monday 06 November 2006 13:12, Simon Riggs wrote:
On Mon, 2006-11-06 at 09:02 +, Dave Page wrote:
Neil Conway wrote:
On Fri, 2006-10-20 at 22:59 +0200, Peter Eisentraut wrote:
Nothing except initdb should add objects in pg_catalog. AFAICS,
adminpack doesn't have any special requirements, so it should behave
like all other contrib modules.
Where are we on this? When this topic was last discussed, the three
alternatives were:
(1) Modify contrib/adminpack to not use the pg_catalog schema,
per the consensus that contrib/ packages installing objects
into that schema is broken behavior
(2) Don't modify contrib/adminpack, for the sake of backward
compatibility
(3) Remove contrib/adminpack from the Postgres distribution
I think the discussion was edging toward #3, but #2 is the only option
that I'm not happy with. Any other opinions out there?
Looking back over the thread, it appears that only you and Peter
objected to it as it is now. Tom, Andreas and myself were of the opinion
it was fine as it is, and whilst he didn't comment on how it should be
implemented, Simon made the point that supporting admin tools from the
core distribution was important which I take to mean he is against #3.
Definitely against #3. [Argument: not just pgAdmin, essential feature]
While I don't disagree that this is an important feature, the fact that it is
being designed with pgadmin specific backwards compatability (for example the
functions that rename core functions) leaves me dubious as to it being a more
general solution. Because of that I would be comfortable with acting on #3.
Now, if I ignore the above, and focus on that I would like to see this
functionality because it helps me with phppgadmin, then I would lean toward
#1 (for a number of reasons really)
Personally I think I'd rather see the whole thing pulled, renamed to its own
schema, and toss in a version function and a kill backend function and let it
go on its merry way... in any case #2 just seems to be the worst of all
possibilities.
--
Robert Treat
Build A Brighter LAMP :: Linux Apache {middleware} PostgreSQL
---(end of broadcast)---
TIP 1: 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] [PATCHES] [BUGS] BUG #2704: pg_class.relchecks overflow
Tom Lane wrote: While there's not anything wrong with this proposed patch in itself, I have to admit that I don't see the point. The points are: 1. It is just unpleasant to leave the overflow. 2. It is not easy for users to understand what they should do when they encounter the error message. At least users can't understand that it is because of the upper limit: ERROR: unexpected constraint record found for rel test_a I haven't found such a case in real practice. But I think the limit will be a little closer than that is now, because constraint exclusion is expanded for UPDATE/DELETE in 8.2 and the opportunity of using check constraint will increase . So I investigated the upper limit and found it. By the way, as you said, it would impose an extra burden on message translators and I can understand your opinion. But will it lead directly to the reason that we don't fix it? Best regards, -- Toru SHIMOGAKI[EMAIL PROTECTED] ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
