Re: InvalidXLogRecPtr in docs
От | Heikki Linnakangas |
---|---|
Тема | Re: InvalidXLogRecPtr in docs |
Дата | |
Msg-id | 4C10AC0D.1010803@enterprisedb.com обсуждение исходный текст |
Ответ на | Re: InvalidXLogRecPtr in docs (Fujii Masao <masao.fujii@gmail.com>) |
Список | pgsql-hackers |
On 10/06/10 11:37, Fujii Masao wrote: > On Thu, Jun 10, 2010 at 5:04 PM, Heikki Linnakangas > <heikki.linnakangas@enterprisedb.com> wrote: >>>> I believe that starting from the beginning of the WAL segment is just >>>> paranoia, to avoid creating a WAL file that's missing some data from the >>>> beginning. Right? >>> >>> Only when the recovery starting record (i.e., the record at the checkpoint >>> redo location) is not found, we need to start replication from the >>> beginning >>> of the segment, I think. That is, fetching_ckpt = true case in the >>> following >>> code. >>> >>>> if (PrimaryConnInfo) >>>> { >>>> RequestXLogStreaming( >>>> fetching_ckpt ? RedoStartLSN : *RecPtr, >>>> PrimaryConnInfo); >>>> continue; >>>> } >> >> Even then, we wouldn't need to start from the beginning of the WAL segment >> AFAICS. The point is to start from the Redo pointer, not from the checkpoint >> record, because as soon as we read the checkpoint record we'll need to start >> applying WAL from the Redo pointer, which is earlier. The WAL file >> boundaries don't come into play there. > > You mean that the WAL file containing the Redo pointer is guaranteed to exist > if we could read the checkpoint record, so we don't need to start from the > beginning of the segment? This is probably true. But what if we could not read > the checkpoint record? In this case, the WAL file containing the Redo pointer > also might not exist. Oh, I think I understand the issue now: we need the header in the beginning of the WAL segment to be valid, even if the first record we're interested in is in the middle of the file. I missed that. -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com
В списке pgsql-hackers по дате отправления: