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