Re: pgsql: Avoid spurious deadlocks when upgrading a tuple lock

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>
Cc: pgsql-committers(at)lists(dot)postgresql(dot)org, Etsuro Fujita <etsuro(dot)fujita(at)gmail(dot)com>
Subject: Re: pgsql: Avoid spurious deadlocks when upgrading a tuple lock
Date: 2019-06-14 15:28:36
Message-ID: 28311.1560526116@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-committers pgsql-hackers

Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> 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 attached? But initializing the variable where it's
declared would certainly silence it.

regards, tom lane

In response to

Responses

Browse pgsql-committers by date

  From Date Subject
Next Message Tom Lane 2019-06-14 15:32:53 Re: pgsql: Avoid spurious deadlocks when upgrading a tuple lock
Previous Message Tom Lane 2019-06-14 15:25:32 pgsql: Attempt to identify system timezone by reading /etc/localtime sy

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2019-06-14 15:32:53 Re: pgsql: Avoid spurious deadlocks when upgrading a tuple lock
Previous Message Heikki Linnakangas 2019-06-14 15:20:29 Allow table AM's to cache stuff in relcache