On Wed, Apr 25, 2012 at 10:16 PM, Noah Misch <noah@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
