Re: Race condition between hot standby and restoring a FPW
От | Heikki Linnakangas |
---|---|
Тема | Re: Race condition between hot standby and restoring a FPW |
Дата | |
Msg-id | 54637CE6.7080207@vmware.com обсуждение исходный текст |
Ответ на | Re: Race condition between hot standby and restoring a FPW (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Race condition between hot standby and restoring a FPW
|
Список | pgsql-hackers |
On 11/12/2014 05:20 PM, Tom Lane wrote: > Heikki Linnakangas <hlinnakangas@vmware.com> writes: >> On 11/12/2014 04:56 PM, Tom Lane wrote: >>> 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? > >> Anyway, you don't want to read the page from disk, just to check if it's >> already valid. > > Oh, good point. > >> (Note that when the page is already in the buffer-cache, RBM_ZERO >> already doesn't zero the page. So this race condition only happens when >> the page isn't in the buffer cache yet). > > Right. > > On reconsideration I think the "RBM_ZERO returns page already locked" > alternative may be the less ugly. That has the advantage that any code > that doesn't get updated will fail clearly and reliably. Yeah, I'm leaning to that approach as well. It's made more ugly by the fact that you sometimes need a cleanup lock on the buffer, so the caller will somehow need to specify whether to get a cleanup lock or a normal exclusive lock. Maybe add yet another mode, RBM_ZERO_WITH_CLEANUP_LOCK. Could also rename RBM_ZERO to e.g. RBM_ZERO_AND_LOCK, to make any code that's not updated to break even more obviously, at compile-time. - Heikki
В списке pgsql-hackers по дате отправления: