From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Simon Riggs <simon(at)2ndquadrant(dot)com> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Reducing relation locking overhead |
Date: | 2005-12-08 15:05:15 |
Message-ID: | 10748.1134054315@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Simon Riggs <simon(at)2ndquadrant(dot)com> writes:
> Further thoughts:
> 1. Normally, we do not lock indexes via the LockMgrLock
> 2. When a REINDEX-like operation comes along, it first of all updates an
> MaintIntentLock flag on the index relation, which causes a relcache
> invalidation. It then waits until all backends have updated their
> relcache.
There isn't any way for it to do that (ie, be sure everyone else has
adjusted to the new state of affairs), short of acquiring some sort of
short-term exclusive lock on the table, which is a really bad idea.
The pending lock would block other incoming requests on the table until
all the current users exited their transactions.
I think the idea of not doing locking on indexes was pretty much shot
down in this thread, and we have to go looking for other solutions ...
thus my other proposal.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Csaba Nagy | 2005-12-08 15:23:57 | Re: Reducing relation locking overhead |
Previous Message | Bruce Momjian | 2005-12-08 15:03:43 | Re: Vertical Partitioning with TOAST |