On Wed, Jul 27, 2005 at 05:12:46PM -0700, Dr NoName wrote:
> Thanks a lot, everyone! That solved my problem. But I
> still want to be able to set transaction timeout. Any
> chance of that in the next release?
No, because feature freeze for the next release is one month past
already.
Anyway, I thi
Dr NoName wrote:
Sure. Like this:
Client A accesses table T, and "hangs."
Client B attempts to get an ACCESS EXCLUSIVE lock on
table T in
preparation for VACUUM FULL.
Client C connects to the database and waits for
client B to get and
release his lock on table T.
Client D connects to the datab
Thanks a lot, everyone! That solved my problem. But I
still want to be able to set transaction timeout. Any
chance of that in the next release?
Eugene
--- Scott Marlowe <[EMAIL PROTECTED]> wrote:
> On Wed, 2005-07-27 at 10:31, Dr NoName wrote:
> > > Sure. Like this:
> > >
> > > Client A acces
On Wed, 2005-07-27 at 10:31, Dr NoName wrote:
> > Sure. Like this:
> >
> > Client A accesses table T, and "hangs."
> > Client B attempts to get an ACCESS EXCLUSIVE lock on
> > table T in
> > preparation for VACUUM FULL.
> > Client C connects to the database and waits for
> > client B to get and
>
> Sure. Like this:
>
> Client A accesses table T, and "hangs."
> Client B attempts to get an ACCESS EXCLUSIVE lock on
> table T in
> preparation for VACUUM FULL.
> Client C connects to the database and waits for
> client B to get and
> release his lock on table T.
> Client D connects to the datab
Dr NoName wrote:
What's the client doing that takes locks strong
enough to "lock up
the entire database"? Why does the client hang?
yeah, good question. I thought postgres uses
better-than-row-level locking? Could the total
deadlock be caused by a combination of an open
transaction and
So can anyone suggest a solution that does not involve
killing the client when it hangs?
thanks,
Eugene
--- Dr NoName <[EMAIL PROTECTED]> wrote:
> > You misunderstood his point. In PostgreSQL
> > parlance, a "cluster" is a
> > single postmaster running on a single machine,
> with
> > 1 or more
On Tue, Jul 26, 2005 at 02:33:04PM -0400, Tom Lane wrote:
> Well, it ought to, but I for one don't consider that code path
> adequately tested --- and we have seen at least one report (from Rod
> Taylor if memory serves) suggesting that there are in fact bugs in it.
>
> We know that SIGTERM'ing al
Scott Marlowe <[EMAIL PROTECTED]> writes:
> On Tue, 2005-07-26 at 12:41, Magnus Hagander wrote:
>> The only *safe* way to do it ATM is to restart the database. SIGTERM may
>> leave orphaned locks or such things in the system.
> Really? I was under the impression that doing a "kill " on
> an idle
> You misunderstood his point. In PostgreSQL
> parlance, a "cluster" is a
> single postmaster running on a single machine, with
> 1 or more
> databases. So, what he wanted to know was, if your
> application is
> hitting a database called fred, and you have a spare
> database named
> wilma, would
On Tue, 2005-07-26 at 12:51, Dr NoName wrote:
> > If you have second database in the cluster is it
> > still operational when
> > the main database locks up?
>
> we don't have a DB cluster. It would be pretty useless
> since postgresql doesn't support distributed
> transactions.
You misunderstoo
> > > > > That said, I have seen some folks post about writing a
> > > perl or shell
> > > > > script that runs every x minutes looking for connections
> > > that have
> > > > > been idle for > a certain amount of time and kill the backend
> > > > > associated with it (sigterm, not -9...)
> > > >
On Tue, 2005-07-26 at 12:41, Magnus Hagander wrote:
> > > > That said, I have seen some folks post about writing a
> > perl or shell
> > > > script that runs every x minutes looking for connections
> > that have
> > > > been idle for > a certain amount of time and kill the backend
> > > > asso
> If you have second database in the cluster is it
> still operational when
> the main database locks up?
we don't have a DB cluster. It would be pretty useless
since postgresql doesn't support distributed
transactions.
> Also it seems that some diagnostics are needed in
> the client app to log
> > > That said, I have seen some folks post about writing a
> perl or shell
> > > script that runs every x minutes looking for connections
> that have
> > > been idle for > a certain amount of time and kill the backend
> > > associated with it (sigterm, not -9...)
> >
> > what are the implic
TIP 2: Don't 'kill -9' the postmaster
Dr NoName wrote:
The common view on this kind of thing is that if
your client is broken,
you need to fix it.
The problem is, we can't fix the users, nor can we fix
other software that our client has to interact with.
There will always be occasional
On Tue, 2005-07-26 at 11:24, Dr NoName wrote:
> > The common view on this kind of thing is that if
> > your client is broken,
> > you need to fix it.
>
> The problem is, we can't fix the users, nor can we fix
> other software that our client has to interact with.
> There will always be occasional
> The common view on this kind of thing is that if
> your client is broken,
> you need to fix it.
The problem is, we can't fix the users, nor can we fix
other software that our client has to interact with.
There will always be occasional situations when a
client gets stuck.
> That said, I have se
> On Tue, Jul 26, 2005 at 08:33:19AM -0700, Dr NoName
> wrote:
>
> > A single client should not be able to bring the
> entire
> > database down. The DB should recognize that the
> client
> > went down and roll back the transaction. That
> would be
> > the ideal solution. Anything else we can do to
> OK, for the third or fourth time, what kind of locks
> is your application
> taking out that can lock the whole database?
I'd like to know that myself. How can a
select/inser/update lock an entire table or even
multiple tables?
> How, exactly, can PostgreSQL (or any other database)
> recognize
> What's the client doing that takes locks strong
> enough to "lock up
> the entire database"? Why does the client hang?
yeah, good question. I thought postgres uses
better-than-row-level locking? Could the total
deadlock be caused by a combination of an open
transaction and VACUUM FULL that run
On Tue, Jul 26, 2005 at 08:33:19AM -0700, Dr NoName wrote:
> A single client should not be able to bring the entire
> database down. The DB should recognize that the client
> went down and roll back the transaction. That would be
> the ideal solution. Anything else we can do to remedy
> the situat
On Tue, 2005-07-26 at 10:33, Dr NoName wrote:
> Yeah, that's what we have to resort to now, but that's
> not a solution. Until we kill the client, the entire
> database is locked (or, at least the tables that other
> clients need to write to, which is effectively the
> same thing). This is annoying
On Tue, 2005-07-26 at 09:40, Dr NoName wrote:
> Hi all,
>
> I have been quite satisfied with the level of support
> from the PostgreSQL community, but this time I'm
> getting nothing. So, is transaction timeout option
> planned at all? What's the alternative solution to a
> client that's hung in t
On Tue, Jul 26, 2005 at 07:40:30AM -0700, Dr NoName wrote:
>
> I have been quite satisfied with the level of support
> from the PostgreSQL community, but this time I'm
> getting nothing.
There have been a couple of replies to your post, although perhaps
not what you were hoping for:
http://archi
Yeah, that's what we have to resort to now, but that's
not a solution. Until we kill the client, the entire
database is locked (or, at least the tables that other
clients need to write to, which is effectively the
same thing). This is annoying enough during the week
but it's especially a problem on
On Tue, Jul 26, 2005 at 07:40:30AM -0700, Dr NoName wrote:
> So, is transaction timeout option planned at all?
> What's the alternative solution to a client that's hung in
> transaction?
Forcibly end it?
--
Alvaro Herrera ()
"I dream about dreams about dreams", sang the nightingale
under the p
Firstly, what are the clients doing to lock the database? Normal
selects, deletes and updates don't really use locks at all.
Secondly, your OS should be noticing when the client dies and telling
PostgreSQL so it can clean up.
Could you provide more detail about what you are actually doing so we
c
Dr NoName <[EMAIL PROTECTED]> writes:
> However, we are repeatedly running into one problem:
> sometimes our client application hangs while in
> transaction and that locks up the entire database, so
> that nothing else can access it.
Why is your client taking such strong locks in the first place?
29 matches
Mail list logo
