[Babase] Postgres
Karl O. Pinc
kop at meme.com
Mon Apr 2 12:03:58 EDT 2007
Tabby and Lacey, please read the part about killing processes.
On 04/01/2007 10:56:50 PM, Tyler Brock wrote:
> Hey everyone,
>
> for some reason the portion of the ranker program I'm working on that
> writes to the database no longer works as the operation times out.
> There seems to be a lot of activity on papio from postmaster
> processes which I cannot kill through the web interface or issuing
> the kill command.
For reasons unknown the top command shows postmaster processes
while the ps command shows postgres processes. It's the postgres
processes you want to kill. (It's a bad idea to kill the
postmaster process, it's the master database coordinator.)
However, you have to be root (or the postgres user) to kill
the postgres processes from Unix because they don't run as you, they
run as the db server's user.
The way to do it is to kill the process from ppa (the web interface),
but you have to login as the database administrator (babase_admin)
to do so. You (and Leah and Tabby and Lacey) should have
the password. (But _please_ don't use it for anything but killing
wayward processes.)
I hope it is not because of me, but I just wanted
> to give you all a heads up and ask for help related to this as I do
> not know if there is something going on, maintenance etc, that would
> make this run much slower than it usually does. Please let me know.
Nope, it's statements you're running. Don't worry, it's inevitable
they'll be problems like this.
Let me know if you think there's a problem in the db. There certainly
could be something related to performance that's
not been optimized and doing very bad things.
You may be having problems because I've been adding "bad" data to
the babase_copy database. In particular I've been putting individuals
into groups much later than when/where they were last censused.
Or, it could be because babase_copy was a copy of babase, which
is an exact copy of the foxpro database and non-conformant to
the new database rules. It's probably time to reload the babase_copy
database with more up-to-date data.
In any case, it's good to track down the pathological cases.
I'd try running the offending statements from the psql
command line and maybe doing analyze and/or explain analyze
on them to get a better feel for what's going on with each
statement.
I don't understand why there should be any timeouts regarding the
database, unless it comes from the tcp stack or libpq detecting
a broken database connection and that does not sound like something
that should be happening. The design of the ranker is up to you
but you should know that ACID compliant databases tend to spend
about as much time canceling an operation as they do running
the operation that's canceled, and they don't always detect cancel
requests synchronously. Sometimes they wait for a completion point
before acting on a cancel request. Also, because it's
client/server just because the client goes away does not
mean that the request is not completed on the
server side. What that all means is that
you can't just stop what your doing and start something new,
the old operation can take a long time to finish and can block
whatever new operation you request. A lot of the time
(but not always obviously) it's a good idea to just let
a long running task finish.
As far as design goes, I'd
rather hear of performance problems from the user than
have them hidden by timeouts and restarts in the application.
Karl <kop at meme.com>
Free Software: "You don't pay back, you pay forward."
-- Robert A. Heinlein
More information about the Babase
mailing list