On 11/5/15 12:14 AM, Jiří Hlinka wrote:
I'm doing simple UPDATES, INSERTs and DELETEs on this table, but
frequency of these DMLs is _very_ high (it is a queue table used for a
one-way selective [just part of data are replicated] replication of
queries between two instances of the database, lets s
On Fri, Nov 6, 2015 at 4:08 PM, Jiří Hlinka wrote:
> my point was, that pg_repack deadlocked itself - I think it should be
> possible to guarantee deadlock-free behavior at least via advisory lock for
> operations of pg_repack itself (I understand it is not possible to guarantee
> this across more
Hi Kevin,
my point was, that pg_repack deadlocked itself - I think it should be
possible to guarantee deadlock-free behavior at least via advisory lock for
operations of pg_repack itself (I understand it is not possible to
guarantee this across more apps). If it is not true, I'd be glad to hear
I'
On Thursday, November 5, 2015 12:16 AM, Jiří Hlinka
wrote:
> My opinion is, that pg_repack should guarantee a consistent,
> deadlock-free behaviour via proper locking policy
I would be very interesting in seeing a description of what locking
policy would guarantee deadlock-free behavior when ru
I'll check if the trigger activity was moving on or waiting for a lock from
logs.
I'm doing simple UPDATES, INSERTs and DELETEs on this table, but frequency
of these DMLs is _very_ high (it is a queue table used for a one-way
selective [just part of data are replicated] replication of queries betw
On Wed, Nov 4, 2015 at 10:16 PM, Jiří Hlinka wrote:
> I'm on pg_repack 1.3.2 (latest sable, no devel version available to check
> if it is already fixed).
>
> Michael: your memories are fresh and clear :-), yes, it is part of a
> cleanup rollback. The problem is, that the pgrepack_drop call this
Thanks Jim and Michael for comments.
I'm on pg_repack 1.3.2 (latest sable, no devel version available to check
if it is already fixed).
Michael: your memories are fresh and clear :-), yes, it is part of a
cleanup rollback. The problem is, that the pgrepack_drop call this
statement:
DROP TABLE IF
On 11/3/15 7:44 AM, Michael Paquier wrote:
I doubt there is anything involving Postgres here. It seems that some
process is still holding a lock on a relation that is being dropped,
caused by a race condition in pg_repack code.
>PS: I was trying a mailing list of pg_repack
>(http://lists.pgfoun
On Tue, Nov 3, 2015 at 9:51 PM, Jiří Hlinka wrote:
> After the 10 min timeout, the OS sends SIGINT to pg_repack process so the
> pg_repack calls:
> SELECT repack.repack_drop($1, $2)
> and it causes a deadlock with other process which is INSERTing into
> frequently_updated_table that has a pg_repac
I'm running a pg_repack from a bash script with timeout of 10 minutes like
so (simplified version):
timeout -s SIGINT 10m pg_repack --table=frequently_updated_table
After the 10 min timeout, the OS sends SIGINT to pg_repack process so the
pg_repack calls:
SELECT repack.repack_drop($1, $2)
and it c
Richard Huxton writes:
> On 05/11/12 18:39, AI Rumman wrote:
>> ERROR: deadlock detected
>> DETAIL: Process 20265 waits for ShareLock on transaction 27774015;
>> blocked by process 20262.
>> Process 20262 waits for ShareLock on transaction 27774018;
>> blocked by process 20265.
>> Process 2026
On 05/11/12 18:39, AI Rumman wrote:
Hi all,
I am using Postrgesql 9.1
I got a message in my log:
ERROR: deadlock detected
DETAIL: Process 20265 waits for ShareLock on transaction 27774015;
blocked by process 20262.
Process 20262 waits for ShareLock on transaction 27774018;
blocked b
Hi all,
I am using Postrgesql 9.1
I got a message in my log:
ERROR: deadlock detected
DETAIL: Process 20265 waits for ShareLock on transaction 27774015; blocked
by process 20262.
Process 20262 waits for ShareLock on transaction 27774018; blocked
by process 20265.
Process 20265:
On Thu, Feb 11, 2010 at 05:01:37PM -0500, Vick Khera wrote:
- On Thu, Feb 11, 2010 at 4:50 PM, David Kerr wrote:
- > currently, i just get "Error: Deadlock Detected" but it doesn't tell me the
tables involved.
- >
-
- Where do you see this? The postgres log file surely has more details.
- Also
On Thu, Feb 11, 2010 at 4:50 PM, David Kerr wrote:
> currently, i just get "Error: Deadlock Detected" but it doesn't tell me the
> tables involved.
>
Where do you see this? The postgres log file surely has more details.
Also, what version etc. etc.
--
Sent via pgsql-general mailing list (pgs
Is there a setting that will give me a more verbose log message when a deadlock
is detected?
currently, i just get "Error: Deadlock Detected" but it doesn't tell me the
tables involved.
Thanks
Dave
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your
Gábor Farkas <[EMAIL PROTECTED]> writes:
> BEGIN; SET TRANSACTION ISOLATION LEVEL SERIALIZABLE;
> now a lot of selects, but nothing complicated, all of the form of "SELECT x
> FROM y WHERE a=b", with some simple joins, and SELECT DISTINCT and ORDER BY.
> END;
>
> can any of these commands cause th
hi,
i got the following error-message:
ERROR: deadlock detected
DETAIL: Process 32618 waits for ShareLock on transaction 1137032034;
blocked by process 16136.
Process 16136 waits for ShareLock on transaction 1137045910;
blocked by process 32618.
(postgres 7.4 here)
i checked the m
> I have a process that is hitting deadlocks. The message I get talks about
> relation and database numbers, not names. How do I map the numbers back
> into names?
Hi,
you need to query the catalog:
-- relations like tables:
select oid, relname from pg_class;
-- databases:
select oid,
I have a process that is hitting deadlocks. The message I get talks about
relation and database numbers, not names. How do I map the numbers back
into names?
David
---(end of broadcast)---
TIP 1: if posting/reading through Usenet, please send an
Clarence Gardner <[EMAIL PROTECTED]> writes:
> The difference I'm asking about is that my artificial ones always involve
> waiting on a transaction, while the ones from the real application always
> involve one transaction wait and one tuple wait.
> The first question is, is there any significance
I am trying to locate the source of some deadlocks that have started
cropping up recently, with little success, and I have a question regarding
the message that accompanies them.
The message my application gets is like this:
Process 244 waits for ShareLock on transaction 39523645; blocked by
proc
On Fri, 2 Dec 2005, Harakiri wrote:
> Hi, thanks for the response ,
>
> >
> > It's hard to say with just the above. Are you doing
> > other things in the
> > transactions besides a single update of that table
> > and/or is the order of
>
> in each transaction i do basically the same stuff :
>
> in
Hi, thanks for the response ,
>
> It's hard to say with just the above. Are you doing
> other things in the
> transactions besides a single update of that table
> and/or is the order of
in each transaction i do basically the same stuff :
insert 1 row into table A, B, C (B and C have a
foreign k
On Fri, 2 Dec 2005, Harakiri wrote:
> im using postgresql 8 under SLES 9 and RH 3.x - under
> both OS i encountered the following problem :
>
> Lets say i have a table, which has no reference to any
> other table - and i create one entry for each day of
> the year within this table (PK). During a
Hello,
im using postgresql 8 under SLES 9 and RH 3.x - under
both OS i encountered the following problem :
Lets say i have a table, which has no reference to any
other table - and i create one entry for each day of
the year within this table (PK). During a day, i
update the values within that spe
On 11/25/05 9:12 PM, "Stephan Szabo" <[EMAIL PROTECTED]> wrote:
> The latter, the row locks before were single owner and were such that a
> second lock request for the same row would wait for the first to be
> released. Now effectively you have two levels of locks at the row level,
> the weaker of
On Fri, 25 Nov 2005, Wes wrote:
> On 11/25/05 2:40 AM, "Stephan Szabo" <[EMAIL PROTECTED]> wrote:
>
> > 8.1 should be using the new shared row locks for doing the checks. This
> > should fix the case mentioned.
>
> Hmm. I'm looking in the "What's new" for 8.1 and see that now. I could
> have sw
On 11/25/05 2:40 AM, "Stephan Szabo" <[EMAIL PROTECTED]> wrote:
> 8.1 should be using the new shared row locks for doing the checks. This
> should fix the case mentioned.
Hmm. I'm looking in the "What's new" for 8.1 and see that now. I could
have sworn it wasn't there the last time I looked.
On Fri, 25 Nov 2005, Wes wrote:
> I haven't seen anything to indicate that 8.x improves foreign key
> refererence locking and fixes the foreign key 'deadlock detected' issue.
> Has that been addressed in 8.1?
8.1 should be using the new shared row locks for doing the checks. This
should fix the
I haven't seen anything to indicate that 8.x improves foreign key
refererence locking and fixes the foreign key 'deadlock detected' issue.
Has that been addressed in 8.1?
I sort my records before loading, but am still getting 'deadlock detected'
(still running 7.3.4).
I have
B references C
B
Hi,
one more question: how can I set up vaccum handling in postgres to make it
less agressive? I'm faceing a problem where a batch process (inserting 184
records at once which takes 1 second in normal cases) stops because of a
dead lock. This occures (seemingly) only when a vacuum analyze is runnin
I am running OSDL-dbt1 - an e-commerce workload
(http://www.osdl.org/lab_activities/kernel_testing/osdl_database_test_suite/osdl_dbt-1/)
against PostgreSQL: 7.3.3. During the test, I saw a lot of messages in
the database log file:
NOTICE: _sc_id=0, _add_flag=0, _itemcount=0, _i_id=597, _pp_i_id=
Hi Tom,
[EMAIL PROTECTED]">"Brian J. France" <[EMAIL PROTECTED]> writes:
I am getting a few of these errors in my web logs and didn't know what I could do to stop it.
NOTICE: Deadlock detected -- See the lock(l) manual page for a possible cause.
Error in query "UPDATE SET = WHER
"Brian J. France" <[EMAIL PROTECTED]> writes:
> I am getting a few of these errors in my web logs and didn't know what I could do
>to stop it.
> NOTICE: Deadlock detected -- See the lock(l) manual page for a possible cause.
> Error in query "UPDATE SET = WHERE = " :
>ERROR: WaitOnLock:
Brian J. France wrote:
>
> BTW, on a different table I get this warning ever time I vacuum the
database. It doesn't seem to cause a problem, but didn't know how to get
rid of it.
>
> NOTICE: Index : NUMBER OF INDEX' TUPLES (214) IS NOT THE
SAME AS HEAP' (215).
> Recreate the index
Hello,
I am getting a few of these errors in my web logs and didn't know what I could do to
stop it.
NOTICE: Deadlock detected -- See the lock(l) manual page for a possible cause.
Error in query "UPDATE SET = WHERE = " :
ERROR: WaitOnLock: error on wakeup - Aborting this transaction
37 matches
Mail list logo
