Avoid spurious deadlocks when upgrading a tuple lock
This puts back reverted commit de87a084c0a5, with some bug fixes.
When two (or more) transactions are waiting for transaction T1 to release a
tuple-level lock, and transaction T1 upgrades its lock to a higher level, a
spurious deadlock can be r
Avoid spurious deadlocks when upgrading a tuple lock
This puts back reverted commit de87a084c0a5, with some bug fixes.
When two (or more) transactions are waiting for transaction T1 to release a
tuple-level lock, and transaction T1 upgrades its lock to a higher level, a
spurious deadlock can be r
Avoid spurious deadlocks when upgrading a tuple lock
This puts back reverted commit de87a084c0a5, with some bug fixes.
When two (or more) transactions are waiting for transaction T1 to release a
tuple-level lock, and transaction T1 upgrades its lock to a higher level, a
spurious deadlock can be r
Avoid spurious deadlocks when upgrading a tuple lock
This puts back reverted commit de87a084c0a5, with some bug fixes.
When two (or more) transactions are waiting for transaction T1 to release a
tuple-level lock, and transaction T1 upgrades its lock to a higher level, a
spurious deadlock can be r
On 2019-Jun-14, Tom Lane wrote:
> I wrote:
> >> Hm, I don't get that warning. Does this patch silence it, please?
>
> > Uh, no patch attached? But initializing the variable where it's
> > declared would certainly silence it.
>
> BTW, after looking around a bit I wonder if this complaint isn't
I wrote:
>> Hm, I don't get that warning. Does this patch silence it, please?
> Uh, no patch attached? But initializing the variable where it's
> declared would certainly silence it.
BTW, after looking around a bit I wonder if this complaint isn't
exposing an actual logic bug. Shouldn't skip_t
Alvaro Herrera writes:
> On 2019-Jun-14, Tom Lane wrote:
>> I'm now getting
>> heapam.c: In function 'heap_lock_tuple':
>> heapam.c:4041: warning: 'skip_tuple_lock' may be used uninitialized in this
>> function
> Hm, I don't get that warning. Does this patch silence it, please?
Uh, no patch at
On 2019-Jun-14, Tom Lane wrote:
> Alvaro Herrera writes:
> > Avoid spurious deadlocks when upgrading a tuple lock
>
> I'm now getting
>
> heapam.c: In function 'heap_lock_tuple':
> heapam.c:4041: warning: 'skip_tuple_lock' may be used uninitialized in this
> function
Hm, I don't get that warn
Alvaro Herrera writes:
> Avoid spurious deadlocks when upgrading a tuple lock
I'm now getting
heapam.c: In function 'heap_lock_tuple':
heapam.c:4041: warning: 'skip_tuple_lock' may be used uninitialized in this
function
Please fix.
regards, tom lane
On 2019-Jun-14, Tatsuo Ishii wrote:
> I am a little bit confused. Here T1 and X are the same transaction?
Argh :-( Yes, X and T1 are the same transaction.
--
Álvaro Herrerahttps://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
I am a little bit confused. Here T1 and X are the same transaction?
Best regards,
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Japanese:http://www.sraoss.co.jp
> Avoid spurious deadlocks when upgrading a tuple lock
>
> When two (or more) transactions are wait
Avoid spurious deadlocks when upgrading a tuple lock
When two (or more) transactions are waiting for transaction T1 to release a
tuple-level lock, and transaction T1 upgrades its lock to a higher level, a
spurious deadlock can be reported among the waiting transactions when T1
finishes. The simpl
Avoid spurious deadlocks when upgrading a tuple lock
When two (or more) transactions are waiting for transaction T1 to release a
tuple-level lock, and transaction T1 upgrades its lock to a higher level, a
spurious deadlock can be reported among the waiting transactions when T1
finishes. The simpl
Avoid spurious deadlocks when upgrading a tuple lock
When two (or more) transactions are waiting for transaction T1 to release a
tuple-level lock, and transaction T1 upgrades its lock to a higher level, a
spurious deadlock can be reported among the waiting transactions when T1
finishes. The simpl
Avoid spurious deadlocks when upgrading a tuple lock
When two (or more) transactions are waiting for transaction T1 to release a
tuple-level lock, and transaction T1 upgrades its lock to a higher level, a
spurious deadlock can be reported among the waiting transactions when T1
finishes. The simpl
15 matches
Mail list logo
