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 по дате отправления: