Hi Michael,
Yes, All the locks are of type= extend.
Is there a way where we can improve the performance of concurrent inserts
on the same table.
Thanks,
Avinash
On Mon, 2020-10-05 at 10:32 +0530, avinash varma wrote:
> Can someone please guide me how to improve/reduce these wait events.
>
> Postgres Version:9.5
>
> LOG: process 3718 still waiting for ExclusiveLock on extension of relation
> 266775 of database 196511 after 1000.057 ms
> Detail: Process h
Are you having locks where the type = extend?
If so, this is a symptom of slow insertsdue to many concurrent
connections trying to insert into the same table at the same time. Each
insert request may result in an extend lock (8k extension), which blocks
other writers. What normally happens is
We are also getting similar warning messages in the log file, for Insert
operation as it is blocking concurrent inserts on the same table. As per
the online documents, I have come across, suggest is because the Postgres
process takes time to search for the relevant buffer in the shared_buffer
area
What is relation 266775 of database 196511? Is
it cms_c207c1e2_0ce7_422c_aafb_77d43f61e563.cms_item or some system catalog
table?
When I search google for "ExclusiveLock on extension of relation" I find
one thread about shared_buffers being very high but not big enough to fit
the entire data in th
Hi Team,
Can someone please guide me how to improve/reduce these wait events.
Postgres Version:9.5
LOG: process 3718 still waiting for ExclusiveLock on extension of relation
266775 of database 196511 after 1000.057 ms
*Detail:* Process holding the lock: 6423. Wait queue: 3718, 4600, 2670,
4046.
