Map forks (WIP)

I've been experimenting with different ways to implement the map forks,
for FSM and visibility map. Attached is my first attempt. I've hacked
together an FSM implementation that uses a fork, to have something to
test with, but the FSM implementation is still very much WIP, so please
ignore freespace.c and indexfsm.c for now. The rest of the code is WIP
as well, but it does compile and pass regression tests.

A relation fork is represented by PhysFileNode, which is
RelFileNode+ForkNumber. smgr.c/md.c now deal with PhysFileNodes instead
of RelFileNodes, as well as a bunch of other places related to that.
Each fork gets its own SMgrRelation.

In RelationData, rd_smgr is now an array of SMgrRelations, one per fork.
In bufmgr.c, there's a new variant of ReadBuffer that takes a ForkNumber
as extra argument.

One difficulty is to decide when the extra forks are created and
dropped. The way it works now is that for a heap, all the required forks
(the main fork that contains the actual data and the FSM fork at the
moment) are created in heap_create. In indexes, it's indexam-specific
which forks are required, so only the main fork is created in
heap_create, and it's up to the indexam build-function to create any
additional forks if necessary. There's a few places, like
copy_relation_data, that need to test which forks exist, so I've added a
new smgrexists() function for that.

I was planning to refactor the WAL replay code so that the
redo-functions would deal with SMgrRelations directly, and get rid of
the lightweight relation cache in xlogutils.c. However, it turned out to
be harder than I thought, because we use the same code in the redo
cleanup functions that we do during normal operations. And we also use
the lightweight relcache in BuildFlatFiles().

I'm not completely satisfied with the way this looks, so I'll try a
slightly different approach next: Instead of having one SMgrRelation per
fork, add an extra ForkNumber argument to all the smgr functions.

Any thoughts, ideas?

PS. If you're wondering what's taking me so long: I've been dragged into
other stuff and haven't had much time to work on this :-(.

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