| From: | Josh Berkus <josh(at)agliodbs(dot)com> |
|---|---|
| To: | pgsql-hackers(at)postgresql(dot)org |
| Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Simon Riggs <simon(at)2ndquadrant(dot)com>, testperf-general(at)pgfoundry(dot)org |
| Subject: | Re: [Testperf-general] Re: ExclusiveLock |
| Date: | 2004-11-18 22:02:22 |
| Message-ID: | 200411181402.22608.josh@agliodbs.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Tom,
> I think you are right that these reflect heap or btree-index extension
> operations. Those do not actually take locks on the *table* however,
> but locks on a single page within it (which are completely orthogonal to
> table locks and don't conflict). The pg_locks output leaves something
> to be desired, because you can't tell the difference between table and
> page locks.
Aside from foriegn keys, though, is there any way in which INSERT page locks
could block other inserts? I have another system (Lyris) where that
appears to be happening with 32 concurrent INSERT streams. It's possible
that the problem is somewhere else, but I'm disturbed by the possibility.
--
--Josh
Josh Berkus
Aglio Database Solutions
San Francisco
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2004-11-18 22:09:33 | Re: OpenBSD/Sparc status |
| Previous Message | Tom Lane | 2004-11-18 21:46:02 | Re: Test database for new installs? |