| 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:13:12 |
| Message-ID: | Pine.BSO.4.10.10010230111040.22422-100000@spider.pilosoft.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Mon, 23 Oct 2000, Alex Pilosov wrote:
> 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 just realised that I _am_ in above my head, and the above makes no
sense, and is identical to holding AccessShareLock.
Sorry ;)
-alex
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Alex Pilosov | 2000-10-23 05:21:08 | Re: relation ### modified while in use |
| Previous Message | Tom Lane | 2000-10-23 05:11:08 | Re: relation ### modified while in use |