On Wed, Apr 25, 2012 at 10:16 PM, Noah Misch <n...@leadboat.com> wrote: >> > Past discussions have raised the issue of interaction between commands like >> > ALTER TABLE and sessions using the new-variety temporary table. ?As a first >> > cut, let's keep this simple and have ongoing use of the table block >> > operations >> > requiring AccessExclusiveLock. ?Note that you can always just make a new >> > temporary table with a different name to deploy a change quickly. >> > ?Implement >> > this with a heavyweight lock having a novel life cycle. ?When a session >> > first >> > takes an ordinary relation lock on the table, acquire the longer-term lock >> > and >> > schedule it for release on transaction abort. ?On TRUNCATE, schedule a >> > release >> > on transaction commit. ?Of course, also release the lock at session end. >> >> I'm not sure I believe this will work, but maybe I'm just not understanding >> it. > > Did you have a specific doubt? I did gloss over all the details, having not > worked them out yet.
Not really. I think the basic idea of keeping the lock for the lifetime of the session is probably sound, modulo those details. The only problem I see is that it would prevent user A from clustering the table while user B is selecting from the table, which is not a priori necessary. It might be useful to work out a solution to that problem somehow, maybe just by jiggering the required lock levels for certain operations - perhaps CLUSTER and VACUUM could run with just RowExclusiveLock when run against a GTT, or something like that. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
