Re: Two-phase commit

Fabien COELHO <coelho(at)cri(dot)ensmp(dot)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