| From: | Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com> |
|---|---|
| To: | Kevin Grittner <Kevin(dot)Grittner(at)wicourts(dot)gov> |
| Cc: | drkp(at)csail(dot)mit(dot)edu, pgsql-hackers(at)postgresql(dot)org |
| Subject: | Re: reindex creates predicate lock on index root |
| Date: | 2011-06-08 06:15:14 |
| Message-ID: | 4DEF1372.3020603@enterprisedb.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On 08.06.2011 06:37, Kevin Grittner wrote:
> You're right; that one was a false alarm. While REINDEX was reading
> the heap to build the index it got an SIREAD lock on a *heap* page.
We never take locks on heap pages directly, so it must've been a
promotion from heap tuple locks.
> While that could arguably be avoided, even though the heap is being
> read in a serializable transaction, I'm not inclined to get really
> excited about it. If someone wants to dodge it, they can always run
> the REINDEX in READ COMMITTED or REPEATABLE READ mode. Maybe 9.2
> material if there's nothing to do that matters more than that.
That should be pretty easy to avoid, though. I think we should fix it now.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Florian Pflug | 2011-06-08 08:14:09 | Re: [PATCH] Bug in XPATH() if expression returns a scalar value |
| Previous Message | Merlin Moncure | 2011-06-08 05:59:00 | Re: WALInsertLock contention |