Skip site navigation (1) Skip section navigation (2)

Re: Refactoring xlogutils.c

From: "Heikki Linnakangas" <heikki(at)enterprisedb(dot)com>
To: "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: "pgsql-patches" <pgsql-patches(at)postgresql(dot)org>
Subject: Re: Refactoring xlogutils.c
Date: 2008-06-11 06:20:35
Message-ID: 484F6EB3.7060200@enterprisedb.com (view raw or flat)
Thread:
Lists: pgsql-patches
Tom Lane wrote:
> "Heikki Linnakangas" <heikki(at)enterprisedb(dot)com> writes:
>> Attached is an updated version of my patch to refactor the
>> XLogOpenRelation/XLogReadBuffer interface, in preparation for the 
>> relation forks patch, and subsequently the FSM rewrite patch.
> 
> The code motion in md.c looks fairly bogus; was that a copy-and-paste
> error?

This one?

> *** a/src/backend/storage/smgr/md.c
> --- b/src/backend/storage/smgr/md.c
> ***************
> *** 208,216 **** mdcreate(SMgrRelation reln, bool isRedo)
>         char       *path;
>         File            fd;
>   
> -       if (isRedo && reln->md_fd != NULL)
> -               return;                                 /* created and opened already... */
> - 
>         Assert(reln->md_fd == NULL);
>   
>         path = relpath(reln->smgr_rnode);
> --- 208,213 ----

That's intentional. That check has been moved to smgrcreate(), so that 
it's done before calling TablespaceCreateDbSpace(). The reason for that 
is that smgrcreate() is now called for every XLogReadBuffer() 
invocation, so we want to make it exit quickly if there's nothing to do.

On second look though, I think we should actually leave that check in 
mdcreate(). Even though it'd be dead code since we do the same check in 
smgrcreate already, removing it changes the semantics of mdcreate(): 
it'd no longer be acceptable to call mdcreate() if the file is open already.

> Otherwise it looks pretty sane, but I have one stylistic gripe:
> I'm dubious about your willingness to assume that pfree() is enough for
> getting rid of a fake relcache entry.  Relcache entries are complex
> beasts and it may not continue to work to do that.  It's also possible
> that we'd have additional resources attached to them someday.  So
> I think it'd be worth having a FreeFakeRelcacheEntry() routine to
> localize the knowledge of how to get rid of them.

Yeah, I guess you're right.

-- 
   Heikki Linnakangas
   EnterpriseDB   http://www.enterprisedb.com

In response to

Responses

pgsql-patches by date

Next:From: Tom LaneDate: 2008-06-11 13:56:03
Subject: Re: Refactoring xlogutils.c
Previous:From: Heikki LinnakangasDate: 2008-06-11 06:08:48
Subject: Re: Refactoring xlogutils.c

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group