"Thomas Chille" <[EMAIL PROTECTED]> writes:
> I think this are the relevant pg_locks entries:
> relation7568577875686189
> 9017862 25467 AccessShareLock f
> relation7568577875686189
> 9009323 9317ShareU
"Thomas Chille" <[EMAIL PROTECTED]> writes:
> Ah ok, 9293 is a triggerd process and tries to "ALTER TABLE ...
> DISABLE TRIGGER (other trigger)" and so implicitly tries to acquire an
> AccessExclusiveLock and runs in a deadlock?
Well, you're certainly risking deadlock with that; and even if no
act
On Nov 27, 2007 4:52 PM, Tom Lane <[EMAIL PROTECTED]> wrote:
> You didn't happen to note what 9293 was doing did you? It's living
> fairly dangerously in any case by trying to acquire exclusive lock
> when it already holds a bunch of other lower-level locks; that's a
> recipe for deadlock if I eve
yes, u are right.
this are the 3 involved indexes:
hst_timerecording_business_day_idx on hst_timerecording
hst_timerecording_id_employee_idxon hst_timerecording
hst_timerecording_id_timerecording_idxon hst_timerecording
lg t
On Nov 27, 2007 4:07 PM, Alvaro Herrera <[EMAIL PROTECTED]> wrote:
> A
Alvaro Herrera wrote:
> Thomas Chille wrote:
> > On Nov 27, 2007 3:14 PM, Alvaro Herrera <[EMAIL PROTECTED]> wrote:
> > hat are the column headings? I find this difficult to read.
> > >
> > > Please post the whole of pg_locks. I may be missing something but I
> > > think we're missing part of the
Thomas Chille wrote:
> On Nov 27, 2007 3:14 PM, Alvaro Herrera <[EMAIL PROTECTED]> wrote:
> hat are the column headings? I find this difficult to read.
> >
> > Please post the whole of pg_locks. I may be missing something but I
> > think we're missing part of the picture here. Autovacuum does no
On Nov 27, 2007 3:14 PM, Alvaro Herrera <[EMAIL PROTECTED]> wrote:
hat are the column headings? I find this difficult to read.
>
> Please post the whole of pg_locks. I may be missing something but I
> think we're missing part of the picture here. Autovacuum does not seem
> to be locking on anyth
Thomas Chille wrote:
> I think this are the relevant pg_locks entries:
>
> relation7568577875686189
> 9017862 25467 AccessShareLock f
> relation7568577875686189
> 9009323 9317ShareUpdateExclusiveLock
>
On Nov 24, 2007 6:20 AM, Tom Lane <[EMAIL PROTECTED]> wrote:
> What other indexes does that table have?
>
> regards, tom lane
>
Hi,
last night it happend again. In the log-snippet u can see all indexes
of this table:
[9293 / 2007-11-26 21:46:28 CET]CONTEXT: SQL statement
"Thomas Chille" <[EMAIL PROTECTED]> writes:
> One Autovacuum process stuck in the middle of the night and it seemed
> that it compete with another Select process for an index:
> [14391 / 2007-11-21 00:52:14 CET]DEBUG: 0: index
> "hst_timerecording_id_timerecording_idx" now contains 8537 row
>
i have to wait till monday, then i can provide these lines.
thanks,
thomas
On Nov 23, 2007 1:32 PM, Alvaro Herrera <[EMAIL PROTECTED]> wrote:
> Thomas Chille escribió:
>
> > This are the last log entires for these both processes. Over 9 hours
> > later, i can see them allready running in the pro
Thomas Chille escribió:
> This are the last log entires for these both processes. Over 9 hours
> later, i can see them allready running in the process list :
>
> 14391 ?S 0:00 postgres: autovacuum process
> backoffice_db
> 14398 ?S 0:02 postgres: spoon backoffice_db off
Hi anybody,
I step in just one of our identically customer databases in a kind of
a deadlock with Autovacuum involved.
One Autovacuum process stuck in the middle of the night and it seemed
that it compete with another Select process for an index:
[14398 / 2007-11-21 00:52:04 CET]CONTEXT: SQL st
13 matches
Mail list logo
