Re: max_standby_delay considered harmful
От | Heikki Linnakangas |
---|---|
Тема | Re: max_standby_delay considered harmful |
Дата | |
Msg-id | 4BE7F56D.1020305@enterprisedb.com обсуждение исходный текст |
Ответ на | Re: max_standby_delay considered harmful (Florian Pflug <fgp@phlo.org>) |
Ответы |
Re: max_standby_delay considered harmful
|
Список | pgsql-hackers |
Florian Pflug wrote: > On May 10, 2010, at 11:43 , Heikki Linnakangas wrote: >> If you're not going to apply any more WAL records before shutdown, you >> could also just release all the AccessExclusiveLocks held by the startup >> process. Whatever the transaction was doing with the locked relation, if >> we're not going to replay any more WAL records before shutdown, we will >> not see the transaction committing or doing anything else with the >> relation, so we should be safe. Whatever state the data on disk is in, >> it must be valid, or we would have a problem with crash recovery >> recovering up to this WAL record and then starting up too. > > Sounds plausible. But wouldn't this imply that HS could *always* postpone the acquisition of an AccessExclusiveLocks untilright before the corresponding commit record is replayed? If fail to see a case where this would fail, yet recoveryin case of an intermediate crash would be correct. I guess it could in some situations, but for example the AccessExclusiveLock taken at the end of lazy vacuum to truncate the relation must be held during the truncation, or concurrent readers will get upset. -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com
В списке pgsql-hackers по дате отправления: