Fabien COELHO <coelho@cri.ensmp.fr> writes:
> Sorry for this stupid general comment, but why couldn't the gid be stored
> in some shared system table that would rely on pg infrastructure for
> caching, sharing, locking and so on?
That would have a number of pitfalls of its own:
* No outside-a-transaction access is possible. This may or may not be
essential, given Heikki's speculations elsewhere about allowing
COMMIT/ROLLBACK PREPARED to be inside transactions, but I think we'd be
foolish to rule it out in a mechanism that is itself transactional
infrastructure.
* We don't have a datatype to represent held locks, nor one for files
slated for deletion. This is fixable in itself, but more work. And do
we really want to commit to developing a datatype for every little bit
of state that may end up being associated with a GID?
* Lots and lots of short-lived entries is not the optimal performance
case for Postgres' tables. It should work well enough in a filesystem
directory though.
regards, tom lane
