Re: Two-phase commit

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