| From: | Manfred Koizar <mkoi-pg(at)aon(dot)at> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | simon(at)2ndquadrant(dot)com, Alvaro Herrera <alvherre(at)dcc(dot)uchile(dot)cl>, Merlin Moncure <merlin(dot)moncure(at)rcsonline(dot)com>, Gavin Sherry <swm(at)linuxworld(dot)com(dot)au>, Hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Shared row locking |
| Date: | 2004-12-30 23:17:09 |
| Message-ID: | sr09t0ho5bvm13piiq0pfdpttfogv02m88@email.aon.at |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Thu, 30 Dec 2004 13:36:53 -0500, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>Certainly not; indexes depend on locks, not vice versa. You'd not be
>able to do that without introducing an infinite recursion into the
>system design.
Wouldn't you have to face the same sort of problems if you spill part of
the lock table to disk? While you do I/O you have to hold some lock.
In either case there has to be a special class of locks that are pinned
in memory.
> In any case nbtree is much more heavyweight than we need
>for this
Having funcionality we don't need is not a showstopper ... unless
heavyweight implies slow, which I have to admit may well be the case.
Servus
Manfred
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Simon Riggs | 2004-12-31 00:04:48 | Re: [HACKERS] Bgwriter behavior |
| Previous Message | Tom Lane | 2004-12-30 19:30:35 | Re: buildfarm NetBSD/m68k tsearch regression failure |