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

Re: Map forks (WIP)

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: Map forks (WIP)
Date: 2008-06-02 13:12:03
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-patches
Tom Lane wrote:
> The XLogOpenRelationWithFork stuff needs to be re-thought also,
> as again this is blurring the question of what's a logical and
> what's a physical relation --- and if forknum isn't part of the
> relation ID, that API is wrong either way.  I'm not sure about
> a good solution in this area, but I wonder if the right answer
> might be to make the XLOG replay stuff use SMgrRelations instead
> of bogus Relations.  IIRC the replay code design predates the
> existence of SMgrRelation, so maybe we need a fresh look there.

I joggled this around for a while, and settled on removing 
XLogOpenRelation altogether, and modifying XLogReadBuffer so that it 
takes RelFileNode directly as argument. XLogReadBuffer takes care of 
calling smgropen and creating missing files, like XLogOpenRelation used 
to. This fits nicely with the changes required for relation forks: the 
blurring of logical and physical goes away with XLogOpenRelation, as 
XLogReadBuffer clearly works at the physical level.

To support functions that really do need a Relation object, like b-tree 
cleanup routine which needs to insert a new index pointer to parent 
page, which uses the same code that's used during normal operation, 
there's a function XLogFakeRelcacheEntry that let's you create a fake 
relcache entry just like XLogOpenRelation used to.

There's one ugly modularity violation in the patch: in XLogReadBuffer, 
I'm checking "if(smgr->md_fd == NULL)", to avoid calling smgrcreate if a 
relation has already been accessed. I'm seeing two possible solutions to 
it: push the functionality to smgr.c by adding a new function 
smgropenandcreate that opens a relation and creates it if it doesn't 
exist, or just document the wart in comments. I'm leaning towards just 
documenting it.

Attached is a patch with just these refactorings, no relation fork or 
FSM stuff included. I'm planning to commit this first, followed by the 
patch to introduce relation forks, followed by FSM rewrite patch. I 
think we're almost there with this refactoring patch and relation forks. 
FSM still needs a fair amount of closing up loose ends, clean up, and 

Ps. The ReadBuffer interface is getting out of hand. This patch 
introduces one more ReadBuffer variant, ReadBufferWithoutRelcache, and 
the upcoming relation forks patch will again introduce at least one new 

   Heikki Linnakangas

Attachment: xlogutils-refactor-1.patch
Description: text/x-diff (66.4 KB)

In response to

pgsql-patches by date

Next:From: Tom LaneDate: 2008-06-02 14:17:02
Subject: Re: Feature: give pg_dump a WHERE clause expression
Previous:From: Gregory StarkDate: 2008-06-02 12:07:25
Subject: Re: Feature: give pg_dump a WHERE clause expression

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