Re: Temporary tables under hot standby
От | Robert Haas |
---|---|
Тема | Re: Temporary tables under hot standby |
Дата | |
Msg-id | CA+TgmoaEmuDn57G+FtqjtZPuY3wAQOOrKzuN8C5Qg1YkKq=3JA@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Temporary tables under hot standby (Noah Misch <noah@leadboat.com>) |
Список | pgsql-hackers |
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
В списке pgsql-hackers по дате отправления: