Victor Sterpu; Merlin Moncure
>> Cc: PostgreSQL General
>> Subject: Re: [GENERAL] Lock problem
>>
>> I'm sure is not right, but is a there a server side solution for such
>> sitations?
>> A configuration - timeout for idle transactions.
>>
>
> I don&#
On 02 Apr 2014, at 20:13, Victor Sterpu wrote:
> There may pass a few days or weeks until next lock.
> But I don't undesrtand why the whole table is locked if there is one
> uncommited transaction.
>
> The following scenario might be the cause:
> 1. Transaction is started
> 2. the client appli
> -Original Message-
> From: pgsql-general-ow...@postgresql.org [mailto:pgsql-general-
> ow...@postgresql.org] On Behalf Of Victor Sterpu
> Sent: Wednesday, April 02, 2014 2:25 PM
> To: Victor Sterpu; Merlin Moncure
> Cc: PostgreSQL General
> Subject: Re: [GENERAL]
uot;
Sent: 4/2/2014 9:13:22 PM
Subject: Re[2]: [GENERAL] Lock problem
There may pass a few days or weeks until next lock.
But I don't undesrtand why the whole table is locked if there is one
uncommited transaction.
The following scenario might be the cause:
1. Transaction is started
2. t
Sent: 4/2/2014 7:19:06 PM
Subject: Re: [GENERAL] Lock problem
I followed all your advice and it is obiuos that this log will show
exactly what I need to debug the situation.
Great tip, thank you.
-- Original Message --
From: "Merlin Moncure"
To: "Victor Sterpu"
Cc:
I followed all your advice and it is obiuos that this log will show
exactly what I need to debug the situation.
Great tip, thank you.
-- Original Message --
From: "Merlin Moncure"
To: "Victor Sterpu"
Cc: "PostgreSQL General"
Sent: 4/2/2014 7:08:08
On Wed, Apr 2, 2014 at 11:00 AM, Victor Sterpu wrote:
> All my transactions have commit or rollback.
Well, you have to verify that. There's a couple of ways to do it.
Probably the most direct is to:
1. Make sure database is logging pids in log_line_prefix (this is a
good idea all around)
2. turn
-- Original Message --
From: "Igor Neyman"
To: "Victor Sterpu" ; "pgsql-general@postgresql.org"
Sent: 4/2/2014 6:29:17 PM
Subject: RE: [GENERAL] Lock problem
From: pgsql-general-ow...@postgresql.org
[mailto:pgsql-general-ow...@postgresql.org] On
-- Original Message --
From: "Merlin Moncure"
To: "Victor Sterpu"
Cc: "PostgreSQL General"
Sent: 4/2/2014 6:49:28 PM
Subject: Re: [GENERAL] Lock problem
On Wed, Apr 2, 2014 at 10:19 AM, Victor Sterpu wrote:
Hello
I have a problem that it
-- Original Message --
From: "Tom Lane"
To: "Victor Sterpu"
Cc: pgsql-general@postgresql.org
Sent: 4/2/2014 6:31:13 PM
Subject: Re: [GENERAL] Lock problem
"Victor Sterpu" writes:
I have a problem that it seems to be very hard to debug.
Problem is
On Wed, Apr 2, 2014 at 10:19 AM, Victor Sterpu wrote:
>
> Hello
>
> I have a problem that it seems to be very hard to debug.
> Problem is from some postgresql locks. I use PostgreSQL 9.1.8.
>
> I runned this query to fid the locks:
>
> SELECT bl.pid AS blocked_pid,
>a.usename
"Victor Sterpu" writes:
> I have a problem that it seems to be very hard to debug.
> Problem is from some postgresql locks. I use PostgreSQL 9.1.8.
You haven't actually explained what your problem is.
> I runned this query to fid the locks:
> SELECT bl.pid AS blocked_pid, a.usename AS blocked_us
From: pgsql-general-ow...@postgresql.org
[mailto:pgsql-general-ow...@postgresql.org] On Behalf Of Victor Sterpu
Sent: Wednesday, April 02, 2014 11:19 AM
To: pgsql-general@postgresql.org
Subject: [GENERAL] Lock problem
Hello
I have a problem that it seems to be very hard to debug.
Problem is
Hello
I have a problem that it seems to be very hard to debug.
Problem is from some postgresql locks. I use PostgreSQL 9.1.8.
I runned this query to fid the locks:
SELECT bl.pid AS blocked_pid, a.usename AS blocked_user, kl.pid AS
blocking_pid, ka.usename AS blocking_user, a.current_query AS
b
I'm sorry Tom.
This happens (at least) both in 8.4 and 9.0. I've just tested it in 2
different databases with the same results.
I have workarounds to this, but I was wondering what could be the actual
root of the problem, in order to (try to) achieve the best solution
possible.
Following is a tes
Eduardo Piombino writes:
> I don't see how a new update to the same record in A, makes the difference
> to allow or deny the lock on a row on table B;
I think it's probably explained by this:
> PS: The only relation between A and B is that A has a two FKs to B, but none
> of them are even includ
Hello list, I'm having a locking problem and I'm not sure what is causing
it.
I have two pgsql concurrent transactions, running each in a separate
connection to postgres (I can reproduce it from pgadmin).
T1) operates only on table A
begin transaction;
select id from A where id = 100 for update n
marcelo Cortez wrote:
hi Richard ,folks
Question: is normal this locks ?
which is the reason of this?
As I said - I don't see any locks that could cause you problems. Can you
provide the error message showing locks timing out?
--
Richard Huxton
Archonet Ltd
hi Richard ,folks
Question: is normal this locks ?
which is the reason of this?
thanks for your time
best regards
MDC
--- Richard Huxton escribió:
> marcelo Cortez wrote:
> > Richard
> >
> > Sorry for a delay
> >
> > question the select * from pg_stat_activity
> > thows
--- Richard Huxton escribió:
> marcelo Cortez wrote:
> > Hi Richard , folks
> >
> > the query is:
> >
> > SELECT c.actuacion_car AS c_actuacion,
> > c.comentario1 || ' ' || c.comentario2 || ' ' ||
> > c.comentario3 AS c_comentario
> > FROM caratult AS c INNER JOIN extractt AS t1 ON
> ...et
Richard
Sorry for the delay.
question, the select * from pg_stat_activity
thows
datid|datname|procpid|usesysid|usename|current_query|query_start
52800|"sume"|30124|1|"postgres"|""|"2005-09-01
13:30:02.921844-03"
52800|"sume"|30125|1|"postgres"|""|"2005-09-01
13:37:21.631802-03"
52800|"
marcelo Cortez wrote:
Hi Richard , folks
the query is:
SELECT c.actuacion_car AS c_actuacion,
c.comentario1 || ' ' || c.comentario2 || ' ' ||
c.comentario3 AS c_comentario
FROM caratult AS c INNER JOIN extractt AS t1 ON
...etc
I'm not seeing anything here that should take locks, although
Hi Richard , folks
the query is:
SELECT c.actuacion_car AS c_actuacion,
c.comentario1 || ' ' || c.comentario2 || ' ' ||
c.comentario3 AS c_comentario
FROM caratult AS c INNER JOIN extractt AS t1 ON
(c.id_extracto_car = t1.id_extracto)
INNER JOIN repartit AS r1 ON (c.id_reparticion_uc =
r1.id_
marcelo Cortez wrote:
hi all
I have a lock problem, one select query freeze my
application, the query in question is on complex
select
An ordinary select doesn't take any locks. What is the actual query
causing this?
--
Richard Huxton
Archonet Ltd
---(end of b
hi all
I have a lock problem, one select query freeze my
application, the query in question is on complex
select , with many join's, but select all of them.
The select * from pg_catalog.pg_locks show many rows
while the query freeze my aplication.
the aplication use ODBC .
any ideas?.
any help
Tom,
Thanks. Running ipcclean fixed it right away.
Travis Bauer | CS Grad Student | IU |www.cs.indiana.edu/~trbauer
On Mon, 9 Oct 2000, Tom Lane wrote:
> Travis Ba
Travis Bauer <[EMAIL PROTECTED]> writes:
> When I start postmaster, I get the following:
> IpcSemaphoreCreate: semget failed (No space left on device) key = ...
> However, it normall works fine with the setting, and a nasty
> crash killed it this morning. I think that for some reason, some
> se
When I start postmaster, I get the following:
IpcSemaphoreCreate: semget failed (No space left on device) key = ...
I know that this is caused by not having enough semaphores and can be
fixed by increasing some settings.
However, it normall works fine with the setting, and a nasty
crash kill
28 matches
Mail list logo
