Re: LogStandbySnapshot (was another thread)
От | Simon Riggs |
---|---|
Тема | Re: LogStandbySnapshot (was another thread) |
Дата | |
Msg-id | 1273133033.12659.32.camel@ebony обсуждение исходный текст |
Ответ на | Re: LogStandbySnapshot (was another thread) (Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>) |
Список | pgsql-hackers |
On Wed, 2010-05-05 at 09:12 +0300, Heikki Linnakangas wrote: > I concur that the idea is that we deal at replay with the fact that the > snapshot lags behind. At replay, any locks/XIDs in the snapshot that > have already been committed/aborted are ignored. For any locks/XIDs > taken just after the snapshot was taken, the replay will see the other > WAL records with that information. > > We need to add comments explaining all that. The attached comments are proposed. Reviewing this information again to propose a fix for the two minor other bugs pointed out by Tom show that they are both related and need one combined fix that would work like this: Currently we handle the state STANDBY_INITIALIZED incorrectly. We need to run RecordKnownAssignedXids() during this mode, so that we both extend the clog and record known xids. That means that two other callers of RecordKnownAssignedXids also need to call it at that time. In ProcArrayApplyRecoveryInfo() we run KnownAssignedXidsAdd(), though this will fail if there are existing xids in there, now it is sorted. So we need to: run KnownAssignedXidsRemovePreceding(latestObservedXid) to remove extraneous xids, then extract any xids that remain and add them to the ones arriving with the running xacts record. We then need to sort the combined array and re-insert into KnownAssignedXids. Previously, I had imagined that the gap between the logical checkpoint and the physical checkpoint was small. With spread checkpoints this isn't the case any longer. So I propose adding a special WAL record that is inserted during LogStandbySnapshot() immediately before GetRunningTransactionLocks(), so that we minimise the time window between deriving snapshot data and recording it in WAL. Those changes are not especially invasive. -- Simon Riggs www.2ndQuadrant.com
Вложения
В списке pgsql-hackers по дате отправления: