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
- [HACKERS] relation ### modified while in use Alex Pilosov
- Re: [HACKERS] relation ### modified while in use Tom Lane
- Re: [HACKERS] relation ### modified while in use Alex Pilosov
- Re: [HACKERS] relation ### modified while in us... Tom Lane
- Re: [HACKERS] relation ### modified while i... Alex Pilosov
- Re: [HACKERS] relation ### modified wh... Tom Lane
- Re: [HACKERS] relation ### modified wh... Alex Pilosov
- Re: [HACKERS] relation ### modified while i... Alex Pilosov
- Re: [HACKERS] relation ### modified while i... Philip Warner
- Re: [HACKERS] relation ### modified wh... Tom Lane
- Re: [HACKERS] relation ### modifie... Philip Warner
- Re: [HACKERS] relation ### modifie... Hiroshi Inoue
- Re: [HACKERS] relation ### mod... Philip Warner
- Re: [HACKERS] relation ### mod... Tom Lane
- Re: [HACKERS] relation ### mod... Philip Warner
- Re: [HACKERS] relation ### mod... Tom Lane