Hi,
On 2017-12-11 15:15:50 -0500, Robert Haas wrote:
> +* Relation extension locks. Only one process can extend a relation at
> +a time; we use a specialized lock manager for this purpose, which is
> +much simpler than the regular lock manager. It is similar to the
> +lightweight lock mechanism, but is ever simpler because there is only
> +one lock mode and only one lock can be taken at a time. A process holding
> +a relation extension lock is interruptible, unlike a process holding an
> +LWLock.
> +/*-------------------------------------------------------------------------
> + *
> + * extension_lock.c
> + * Relation extension lock manager
> + *
> + * This specialized lock manager is used only for relation extension
> + * locks. Unlike the heavyweight lock manager, it doesn't provide
> + * deadlock detection or group locking. Unlike lwlock.c, extension lock
> + * waits are interruptible. Unlike both systems, there is only one lock
> + * mode.
> + *
> + * False sharing is possible. We have a fixed-size array of locks, and
> + * every database OID/relation OID combination is mapped to a slot in
> + * the array. Therefore, if two processes try to extend relations that
> + * map to the same array slot, they will contend even though it would
> + * be OK to let both proceed at once. Since these locks are typically
> + * taken only for very short periods of time, this doesn't seem likely
> + * to be a big problem in practice. If it is, we could make the array
> + * bigger.
For me "very short periods of time" and journaled metadatachanging
filesystem operations don't quite mesh. Language lawyering aside, this
seems quite likely to bite us down the road.
It's imo perfectly fine to say that there's only a limited number of
file extension locks, but that there's a far from neglegible chance of
conflict even without the array being full doesn't seem nice. Think this
needs use some open addressing like conflict handling or something
alike.
Greetings,
Andres Freund