Re: Hot Standby WAL reply uses heavyweight session locks, but doesn't have enough infrastructure set up

On Tue, Jan 27, 2015 at 6:24 AM, Andres Freund <andres(at)2ndquadrant(dot)com> wrote:
> Unfortunately that Assert()s when there's a lock conflict because
> e.g. another backend is currently connecting. That's because ProcSleep()
> does a enable_timeout_after(DEADLOCK_TIMEOUT, DeadlockTimeout) - and
> there's no deadlock timeout (or lock timeout) handler registered.
Yes, that could logically happen if there is a lock conflicting as
RowExclusiveLock or lower lock can be taken in recovery.

> [...]
> afaics, that should work? Not pretty, but probably easier than starting
> to reason about the deadlock detector in the startup process.
Wouldn't it be cleaner to simply register a dedicated handler in
StartupXlog instead, obviously something else than DEADLOCK_TIMEOUT as
it is reserved for backend operations? For back-branches, we may even
consider using DEADLOCK_TIMEOUT..

> We probably should also add a Assert(!InRecovery || sessionLock) to
> LockAcquireExtended() - these kind of problems are otherwise hard to
> find in a developer setting.
So this means that locks other than session ones cannot be taken while
a node is in recovery, but RowExclusiveLock can be taken while in
recovery. Don't we have a problem with this assertion then?
--
Michael