Lock tag of relation extend lock

Hi all,

In a recent debug I found two process conflict on relation extension lock,
one is holding it for MAIN fork extension, while the other one is trying to
do FSM extension. It seems that the extension lock is using the logical relid
of a table as lock tag, but smgrextend is independant among each fork.

LockRelationForExtension is used to lock out concurrent extension to get an
accurate smgrnblocks (of MAIN fork, mostly) for where to extend the fork from.
Except for that in bufmgr.c, where the forknum is passed in as parameter,
so main/fsm/vm extension shares the code.

Would it be more reasonable to use physical identifier as the lock tag, like
rlocator + fork? In that case, smgr*extend will not block on separate forks.
And also it is easier to share code between recovery and normal operations,
(see what definition of struct BufferManagerRelation says), because currently
relation extension lock needs a relcache to be passed in, and we have to
build a fake relcache during xlog recovery. The lockinfo of the fake relcache
may be wrong actually, although it's not a problem. If we use the physical
information as lock tag, the lockinfo of fake relcache won't be that hack.

Good thing is that different forks of the same relfile can be extended
concurrently by different processes. Not sure about any side effect.

Any thoughts?

--
Regards, Jingtang