>
> > Currently only the first segment is opened when mdopen() etc is
> > called. Would you change to check all segments at first open ?
>
> No, I don't see a need to change that logic. I was thinking that
> since mdnblocks adds another link to the chain whenever it sees that
> the current segment is exactly RELSEG_SIZE, it could just assume that
> if the next-segment link is not NULL then this segment must be of
> size RELSEG_SIZE and it doesn't need to check that again. It'd only
> need to do an actual check on the last chain element (plus any elements
> it adds during the current call, of course). We'd rely on the
> higher-level interlock to close and reopen the virtual file when a
> truncate has happened.
>
You are right.
The last segment is always lseeked.
And does this mean that the first mdnblocks() opens all segments and
checks them ?
> > If there is a relation which has multi-segment of size 0,which would
> > be the last segment ?
>
> Only the last segment can have any size other than RELSEG_SIZE, I think.
>
This may be another issue.
I have been suspicious about current implementation of md.c.
It relies so much on information about existent phisical files.
How do you think about the following ?
1. Partial blocks(As you know,I have changed the handling of this kind of blocks recently).
2. If a backend was killed or crashed in the middle of execution of mdunlink()/mdtruncate(),half of segments
wouldn'tbe unlink/ truncated.
3. In cygwin port,mdunlink()/mdtruncate() may leave segments of 0 length.
4. We couldn't mdcreate() existent files and coudn't mdopen()/md unlink() non-existent files. So there are some
casesthat we could neither CREATE TABLE nor DROP TABLE.
I have no solution but seems the count of valid segments and blocks
should be held in other places.
Regards.
Hiroshi Inoue
Inoue@tpf.co.jp