Re: Race condition between hot standby and restoring a FPW
От | Tom Lane |
---|---|
Тема | Re: Race condition between hot standby and restoring a FPW |
Дата | |
Msg-id | 4351.1415807254@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: 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: > On 11/12/2014 05:20 PM, Tom Lane wrote: >> 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. Yeah, I was considering suggesting changing the name of the mode too. +1 for solving the lock-type problem with 2 modes. (You could also consider leaving RBM_ZERO in place with its current semantics, but I think what you've shown here is that there is no safe way to use it, so probably that's not what we should do.) regards, tom lane
В списке pgsql-hackers по дате отправления: