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
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
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
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
> 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,
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
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
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
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
26 matches
Mail list logo
