Re: Hot Standby WAL reply uses heavyweight session locks, but doesn't have enough infrastructure set up
От | Michael Paquier |
---|---|
Тема | Re: Hot Standby WAL reply uses heavyweight session locks, but doesn't have enough infrastructure set up |
Дата | |
Msg-id | CAB7nPqROBN6WKak0xxyQkqc=7gr+bi+Wp15r8_QAiwaQtSP1wg@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Hot Standby WAL reply uses heavyweight session locks, but doesn't have enough infrastructure set up (Andres Freund <andres@2ndquadrant.com>) |
Ответы |
Re: Hot Standby WAL reply uses heavyweight session locks,
but doesn't have enough infrastructure set up
|
Список | 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 по дате отправления: