| From: | Alex Pilosov <alex(at)pilosoft(dot)com> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | pgsql-hackers(at)postgresql(dot)org |
| Subject: | Re: relation ### modified while in use |
| Date: | 2000-10-23 05:09:50 |
| Message-ID: | Pine.BSO.4.10.10010230104320.22422-100000@spider.pilosoft.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Mon, 23 Oct 2000, Tom Lane wrote:
> when done, but it will deadlock if SELECT does not release that lock.
>
> That's annoying but I see no way around it, if we are to allow
> concurrent transactions to do schema modifications of tables that other
> transactions are using.
I might be in above my head, but maybe this is time for yet another type
of lock? "Do-not-modify-this-table-under-me" lock, which shall persist
until transaction commits, and will conflict only with alter table
lock/AccessExclusiveLock?
I realise we have already many lock types, but this seems to be proper
solution to me...
In related vein: Is there a way to see who (at least process id) is
holding locks on tables?
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2000-10-23 05:11:08 | Re: relation ### modified while in use |
| Previous Message | Tom Lane | 2000-10-23 05:01:05 | Re: relation ### modified while in use |