On 11/12/14, 9:47 AM, Tom Lane wrote:
Heikki Linnakangas <hlinnakan...@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 that means 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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
