On 2015-12-15 11:28:10 -0500, Robert Haas wrote:
> Hmm, yes it does. But now that I think about it, we're not otherwise
> doing _mdnblocks() in that loop. So that would add a system call per
> loop iteration. That doesn't seem like such a swell idea.
We'd do that only when intially open the relation (that far). And after
we've already executed a, much more expensive, open() on the same
file. So I'm not particularly bothered by that.
> If you're OK with it, I think I'll commit the original patch. That
> seems like a good thing to do regardless of what we decide about the
> rest of this.
Ok.
I thought for a moment that that patch would need a bit more editing
because of:
/*
* This is the last segment we want to keep. Truncate
the file to
* the right length, and clear chain link that points
to any
* remaining segments (which we shall zap). NOTE: if
nblocks is
* exactly a multiple K of RELSEG_SIZE, we will
truncate the K+1st
* segment to 0 length but keep it. This adheres to the
invariant
* given in the header comments.
*/
in mdtruncate(). But afaics this doesn't change:
* On disk, a relation must consist of consecutively numbered segment
* files in the pattern
* -- Zero or more full segments of exactly RELSEG_SIZE blocks each
* -- Exactly one partial segment of size 0 <= size < RELSEG_SIZE
blocks
* -- Optionally, any number of inactive segments of size 0 blocks.
at all, so I think we're good.
Andres
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
