Robert Haas <robertmh...@gmail.com> writes:
> On Thu, Dec 10, 2015 at 1:22 PM, Simon Riggs <si...@2ndquadrant.com> wrote:
>> We can seq scan the array at relcache build time and invalidate relcache
>> when we extend. WAL log any extension to a new segment and write the table
>> to disk at checkpoint.
> Invaliding the relcache when we extend would be extremely expensive,
... and I think it would be too late anyway, if backends are relying on
the relcache to tell the truth. You can't require an exclusive lock on
a rel just to extend it, which means there cannot be a guarantee that
what a backend has in its relcache will be up to date with current reality.
I really don't like Robert's proposal of a metapage though. We've got too
darn many forks per relation already.
It strikes me that this discussion is perhaps conflating two different
issues. Robert seems to be concerned about how we'd detect (not recover
from, just detect) filesystem misfeasance in the form of complete loss
of a non-last segment file. The other issue is a desire to reduce the
cost of mdnblocks() calls. It may be worth thinking about those two
things together, but we shouldn't lose sight of these being separate
goals, assuming that anybody besides Robert thinks that the segment
file loss issue is worth worrying about.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
