Re: RFC: Logging plan of the running query

Fujii Masao <masao.fujii@oss.nttdata.com>

From: Fujii Masao <masao.fujii@oss.nttdata.com>

To: Kyotaro Horiguchi <horikyota.ntt@gmail.com>

Cc: torikoshia@oss.nttdata.com, pgsql-hackers@lists.postgresql.org

Date: 2022-02-01T14:11:03Z

Lists: pgsql-hackers

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

ecpg: Catch zero-length Unicode identifiers correctly
- a18b6d2dc288 15.0 cited
Improve warning message in pg_signal_backend()
- 7fa945b857cc 15.0 cited
Add assert to ensure that page locks don't participate in deadlock cycle.
- 72e78d831ab5 13.0 cited


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