Re: RFC: Logging plan of the running query - Mailing list pgsql-hackers

From Fujii Masao
Subject Re: RFC: Logging plan of the running query
Date
Msg-id a398dab8-486c-4a54-5aa6-f9faab2ea1fa@oss.nttdata.com
Whole thread Raw
In response to Re: RFC: Logging plan of the running query  (Kyotaro Horiguchi <horikyota.ntt@gmail.com>)
Responses Re: RFC: Logging plan of the running query  (Kyotaro Horiguchi <horikyota.ntt@gmail.com>)
List pgsql-hackers

On 2022/02/01 17:27, Kyotaro Horiguchi wrote:
>> * Similar to relation extension, page locks are also held for a short
>> * duration, so imposing such a restriction won't hurt.
> 
> I don't believe a path involving vacuum_delay_point() calls is
> short-duration'ed.

Yes.


>> One thing that really bothers me about commit e2c79e14 is that
>> LockPage() is called, not LockBuffer(). GIN had no LockPage() calls
>> before that commit, and is now the only code in the entire system that
>> calls LockPage()/ConditionalLockPage() (the hash am no longer uses
>> page heavyweight locks following recent work there).
> 
> I agree to the discussion.  Can't we use other mechanism here to get
> rid of the Lockpage()?

I have no good idea for that yet, but I agree it's better to get rid of page level lock.

Regards,

-- 
Fujii Masao
Advanced Computing Technology Center
Research and Development Headquarters
NTT DATA CORPORATION



pgsql-hackers by date:

Previous
From: gkokolatos@pm.me
Date:
Subject: Plug minor memleak in pg_dump
Next
From: Bharath Rupireddy
Date:
Subject: Re: Plug minor memleak in pg_dump