On Tue, Jan 27, 2015 at 6:24 AM, Andres Freund <and...@2ndquadrant.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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
