Thread: Access and rules
I am trying to link to a postgres table with rules in Access. Am using the 7.03.00.01 snapshot. Access will not link because it says table with same name already exists. If I drop the rules it will link. Any cure for this? Thank you Adrian Klaver aklaver@attbi.com
> -----Original Message----- > From: Adrian Klaver > > I am trying to link to a postgres table with rules in Access. Am > using the > 7.03.00.01 snapshot. Access will not link because it says table with same > name already exists. If I drop the rules it will link. Any cure for this? What rule are you defining ? regards, Hiroshi Inoue
Sometimes access dies and we have lot of 'zombies' connections in our server, is it possible to kill only this threads without restart database ? Is it sane to make a kill -15 pidofzombiethread ? Thanks a lot ! PostgreSQL 7.1.3 under freeBSD -- Simeó Reig
=?iso-8859-1?Q?Sime=F3_Reig?= <simeo@incofisa.com> writes:
> Sometimes access dies and we have lot of 'zombies' connections in our
> server, is it possible to kill only this threads without restart database ?
If it shows as "zombie" in ps, then you can't kill it (because it's
already dead). kill will have absolutely zero effect.
This should not happen, though. The only way a Postgres child process
could stay as "zombie" for more than a few milliseconds is if the
postmaster is hung up and unable to notice the dead child process.
If the postmaster were hung, you'd have a lot worse problems than zombie
processes --- you'd not be able to make new connections at all. So I
think you aren't giving us the straight scoop. Are you sure that these
zombie processes are actually Postgres processes? Look to see what
their parent process is.
> PostgreSQL 7.1.3 under freeBSD
You could do worse than update to 7.2. It's *much* harder for a
misbehaving client to hang the postmaster than it was pre-7.2.
But I'm not convinced that you're describing a Postgres problem.
regards, tom lane
> If it shows as "zombie" in ps, then you can't kill it (because it's > already dead). kill will have absolutely zero effect. > > This should not happen, though. The only way a Postgres child process > could stay as "zombie" for more than a few milliseconds is if the > postmaster is hung up and unable to notice the dead child process. > If the postmaster were hung, you'd have a lot worse problems than zombie > processes --- you'd not be able to make new connections at all. So I > think you aren't giving us the straight scoop. Are you sure that these > zombie processes are actually Postgres processes? Look to see what > their parent process is. Well, I'm saying 'zombie' not like *nix terminology. I'm talking about server proces that are waiting for a client that die unexpectly and can't close connection. > > PostgreSQL 7.1.3 under freeBSD > > You could do worse than update to 7.2. It's *much* harder for a > misbehaving client to hang the postmaster than it was pre-7.2. > But I'm not convinced that you're describing a Postgres problem. > > regards, tom lane No, no sorry, Postgres is HARDER a lot, we have more than 70 simultaneos connection over ODBC, 107 tables, millions of rows and nothing has happened since april, really good job ! Update the database is in our TODO LIST but we try to wait for a version with native replication (We have heard that is possible to be available in 7.4.X ) . We have still a lot of work and there is a problem with time representation that has changed between 7.1.X to 7.2.X that we can't resolve (decimal fraction of time) and we have a lot of server side code. Thanks! Simeó Reig