Re: Two-phase commit - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Two-phase commit
Date
Msg-id 28489.1097159631@sss.pgh.pa.us
Whole thread Raw
In response to Re: Two-phase commit  (Fabien COELHO <coelho@cri.ensmp.fr>)
List pgsql-hackers
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


pgsql-hackers by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: pgindent complaint of the day
Next
From: Eyinagho Newton
Date:
Subject: Reading from a text file into PostgreSQL