Hi~
> What workload actually has significant enough extension workload on the VM/FSM
> to make this a problem?
The workload I was running is a concurrent INSERT into the same table. I'm
running PostgreSQL with direct I/O on a distributed file system, where the
latency of extend is significantly higher than the local storage, making
conflict of extend lock really serious (it can be mimic by adding
pg_usleep at the end of smgrzeroextend), about 200us once extend.
Most of the conflicts happen on main fork extend, however sometimes the
conflict may happen on FSM because the bulk extended pages need to be added
into FSM. It may be conflict with both main fork extend or fsm fork extend
of other processes. But actually the fsm fork extend does not need to be
conflict with main fork extend?
#5 0x00000000008a717e in WaitOnLock
#6 0x00000000008a7d4b in LockAcquireExtended
#7 0x00000000008a876e in LockAcquire
#8 0x00000000008a584f in LockRelationForExtension
#9 0x000000000087fd6b in ExtendBufferedRelShared
#10 0x00000000008816ab in ExtendBufferedRelCommon
#11 ExtendBufferedRelTo
#12 0x000000000088f538 in fsm_extend
#13 fsm_readbuf
#14 0x000000000088f627 in fsm_set_and_search
#15 0x0000000000501e81 in RelationAddBlocks
--
Regards, Jingtang
