On 11/12/14, 9:47 AM, Tom Lane wrote:
> 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.)
If we're tweaking modes, can we avoid zeroing the buffer if we're about to dump a full page image into it? Presumably
thatmeans we'd have to keep the page locked until the image is written...
--
Jim Nasby, Data Architect, Blue Treble Consulting
Data in Trouble? Get it in Treble! http://BlueTreble.com
