Re: Exceptional md.c paths for recovery and zero_damaged_pages
От | Tom Lane |
---|---|
Тема | Re: Exceptional md.c paths for recovery and zero_damaged_pages |
Дата | |
Msg-id | 1272696.1734134776@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Exceptional md.c paths for recovery and zero_damaged_pages (Andres Freund <andres@anarazel.de>) |
Ответы |
Re: Exceptional md.c paths for recovery and zero_damaged_pages
|
Список | pgsql-hackers |
Andres Freund <andres@anarazel.de> writes: > We have a fair number of special paths in md.c that are specific to > recovery. E.g. in mdreadv() we do: > ... > As far as I can tell, nearly all - including the above - InRecovery paths in > md.c are basically unreachable. And have been for quite a while. > XLogReadBufferExtended() takes care to > a) Create the fork if it doesn't yet exist. > b) Not to read from beyond EOF. If EOF is found, we extend the relation to be > large enough. > Which afaict should suffice to prevent needing the above? I haven't checked the git history, but I suspect this logic is later than the md.c code you mention, and may well render it obsolete. > The InRecovery paths for _mdfd_getseg seem to originate in 2004's 303e46ea932 > and the zero-beyond-eof seems to be from 2007's ef07221997e - although it was > just *restricted* to InRecovery in that commit. We definitely needed 303e46ea932 at the time, but that doesn't mean we still do. Possibly ef07221997e was just copying the earlier logic. regards, tom lane
В списке pgsql-hackers по дате отправления: