Re: standalone backend PANICs during recovery
От | Tom Lane |
---|---|
Тема | Re: standalone backend PANICs during recovery |
Дата | |
Msg-id | 25082.1472563473@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: standalone backend PANICs during recovery (Michael Paquier <michael.paquier@gmail.com>) |
Ответы |
Re: standalone backend PANICs during recovery
|
Список | pgsql-hackers |
Michael Paquier <michael.paquier@gmail.com> writes: > On Tue, Aug 30, 2016 at 9:48 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: >> Hm, StartupXLOG seems like a pretty random place to check that, especially >> since doing it there requires an extra stat() call. Why didn't you just >> make readRecoveryCommandFile() error out? > Well, the idea is to do the check before doing anything on PGDATA and > leave it intact, particularly the post-crash fsync(). I don't see anything very exciting between the beginning of StartupXLOG and readRecoveryCommandFile. In particular, doing the fsync seems like a perfectly harmless and maybe-good thing. If there were some operation with potentially bad side-effects in that range, it would be dangerous anyway because of the risk of readRecoveryCommandFile erroring out due to invalid contents of recovery.conf. This might be an argument for re-ordering what we're doing in StartupXLOG, but that seems like an independent discussion. regards, tom lane
В списке pgsql-hackers по дате отправления: