On Tuesday, June 07, 2011 04:29:02 Robert Haas wrote:
> On Fri, Jun 3, 2011 at 1:01 PM, Alvaro Herrera
>
> <alvherre@commandprompt.com> wrote:
> > Excerpts from Robert Haas's message of vie jun 03 12:44:45 -0400 2011:
> >> On Wed, Jun 1, 2011 at 2:28 PM, Robert Haas <robertmhaas@gmail.com>
wrote:
> >> > (4) It strikes me that it might be possible to address this problem a
> >> > bit more cleanly by allowing mdnblocks() and smgrnblocks() and
> >> > RelationGetNumberOfBlocksInFork() to take a boolean argument
> >> > indicating whether or not an error should be thrown if the underlying
> >> > physical file happens not to exist. When no error is to be signaled,
> >> > we simply return 0 when the main fork doesn't exist, rather than
> >> > throwing an error.
> >>
> >> If we don't want to gum this with the above-mentioned cruft, the other
> >> obvious alternative here is to do nothing, and live with the
> >> non-beauty of the resulting error message.
> >
> > Option 4 seems reasonable to me ... can you get rid of the dupe
> > smgrnblocks call simultaneously?
>
> What dup smgrnblocks call?
>
> Patch along these lines attached.
> diff --git a/src/include/storage/bufmgr.h b/src/include/storage/bufmgr.h
> index b8fc87e..edd1674 100644
> --- a/src/include/storage/bufmgr.h
> +++ b/src/include/storage/bufmgr.h
> @@ -186,7 +186,7 @@ extern void DropRelFileNodeBuffers(RelFileNodeBackend
> rnode,
>
> extern void DropDatabaseBuffers(Oid dbid);
>
> #define RelationGetNumberOfBlocks(reln) \
>
> - RelationGetNumberOfBlocksInFork(reln, MAIN_FORKNUM)
> + RelationGetNumberOfBlocksInFork(reln, MAIN_FORKNUM, true)
>
> #ifdef NOT_USED
> extern void PrintPinnedBufs(void);
That hunk seems to be a bit dangerous given that RelationGetNumberOfBlocks is
used in the executor. Maybe all the callsites are actually safe but it seems
to be too fragile to me.
In my opinion RelationGetNumberOfBlocks should grow missing_ok as well.
Andres