Re: Race condition between hot standby and restoring a FPW
От | Tom Lane |
---|---|
Тема | Re: Race condition between hot standby and restoring a FPW |
Дата | |
Msg-id | 23185.1415804205@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Race condition between hot standby and restoring a FPW (Heikki Linnakangas <hlinnakangas@vmware.com>) |
Ответы |
Re: Race condition between hot standby and restoring a
FPW
|
Список | pgsql-hackers |
Heikki Linnakangas <hlinnakangas@vmware.com> writes: > There's a race condition between a backend running queries in hot > standby mode, and restoring a full-page image from a WAL record. It's > present in all supported versions. > I can think of two ways to fix this: > 1. Have ReadBufferExtended lock the page in RBM_ZERO mode, before > returning it. That makes the API inconsistent, as the function would > sometimes lock the page, and sometimes not. Ugh. > 2. When ReadBufferExtended doesn't find the page in cache, it returns > the buffer in !BM_VALID state (i.e. still in I/O in-progress state). > Require the caller to call a second function, after locking the page, to > finish the I/O. Not great either. What about an RBM_NOERROR mode that is like RBM_ZERO in terms of handling error conditions, but does not forcibly zero the page if it's already valid? regards, tom lane
В списке pgsql-hackers по дате отправления: