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

From Michael Paquier
Subject Re: Hot Standby WAL reply uses heavyweight session locks, but doesn't have enough infrastructure set up
Date
Msg-id CAB7nPqROBN6WKak0xxyQkqc=7gr+bi+Wp15r8_QAiwaQtSP1wg@mail.gmail.com
Whole thread Raw
In response to Re: Hot Standby WAL reply uses heavyweight session locks, but doesn't have enough infrastructure set up  (Andres Freund <andres@2ndquadrant.com>)
Responses Re: Hot Standby WAL reply uses heavyweight session locks, but doesn't have enough infrastructure set up
List pgsql-hackers
Andres Freund wrote:
> I think this isn't particularly pretty, but it seems to be working well
> enough, and changing it would be pretty invasive. So keeping in line
> with all that code seems to be easier.
OK, I'm convinced with this part to remove the call of
LockSharedObjectForSession that uses dontWait and replace it by a loop
in ResolveRecoveryConflictWithDatabase.

> Note that InRecovery doesn't mean what you probably think it means:
> [stuff]
> bool            InRecovery = false;
Yes, right. I misunderstood with RecoveryInProgress().

> The assertion actually should be even stricter:
> Assert(!InRecovery || (sessionLock && dontWait));
> i.e. we never acquire a heavyweight lock in the startup process unless
> it's a session lock (as we don't have resource managers/a xact to track
> locks) and we don't wait (as we don't have the deadlock detector
> infrastructure set up).
No problems with this assertion here.
-- 
Michael



pgsql-hackers by date:

Previous
From: Amit Kapila
Date:
Subject: Re: Parallel Seq Scan
Next
From: Heikki Linnakangas
Date:
Subject: Re: Dereferenced pointers checked as NULL in btree_utils_var.c