From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr> |
Cc: | Heikki Linnakangas <hlinnaka(at)iki(dot)fi>, PostgreSQL Developers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Two-phase commit |
Date: | 2004-10-07 14:33:51 |
Message-ID: | 28489.1097159631@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers pgsql-patches |
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
From | Date | Subject | |
---|---|---|---|
Next Message | Eyinagho Newton | 2004-10-07 14:45:29 | Reading from a text file into PostgreSQL |
Previous Message | Bruce Momjian | 2004-10-07 14:17:08 | Re: pgindent complaint of the day |
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 2004-10-07 19:22:34 | Re: [PATCHES] HP-UX PA-RISC/Itanium 64-bit Patch and HP-UX |
Previous Message | Peter Eisentraut | 2004-10-07 13:00:05 | Re: Support LDFLAGS_SL on most ports |