Once upon a time, I put a question regarding deadlocks to the group,
and Tom Lane immediately answered with this:
>The guy waiting on the tuple-specific lock is second in
>line to actually mung the tuple. Whoever is first in line behind the
>current tenant will be blocked trying to acquire Share
Once upon a time, I put a question regarding deadlocks to the group,
and Tom Lane immediately answered with this:
>The guy waiting on the tuple-specific lock is second in
>line to actually mung the tuple. Whoever is first in line behind the
>current tenant will be blocked trying to acquire ShareL
o that
the order of acquisition of a and b is known? I'm assuming that
there is no ordering implied/guaranteed by "for update of a, b".
Or am I missing something?
Clarence
---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster
h two of them waiting on a locked
tuple?
* Acquire tuple lock to establish our priority for the tuple.
* LockTuple will release us when we are next-in-line for the tuple.
Thanks for any help,
Clarence
---(end of broadcast)---
TIP 6: ex
Tom Lane wrote:
> Um. Extract from the 8.0.5 CVS logs:
>
> 2005-12-08 14:19 tgl
>
> * src/backend/: postmaster/bgwriter.c, utils/resowner/resowner.c
> (REL8_0_STABLE): Fix bgwriter's failure to release buffer pins and
> open files after an error. This probably explains bug #20
Tom Lane wrote:
> "Clarence" <[EMAIL PROTECTED]> writes:
> > I have a completely idle postgresql system (all backends "idle", none
> > "in transaction"); every time I attempt to vacuum a particular table,
> > it hangs after a whil
I have a completely idle postgresql system (all backends "idle", none
"in transaction"); every time I attempt to vacuum a particular table,
it hangs
after a while. Here is the output of vacuumdb:
INFO: vacuuming "public.ledgerdetail"
INFO: index "ledgerdetail_pkey" now contains 11574842 row vers
