| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | "Qingqing Zhou" <zhouqq(at)cs(dot)toronto(dot)edu> |
| Cc: | pgsql-hackers(at)postgresql(dot)org |
| Subject: | Re: unsafe use of hash_search(... HASH_ENTER ...) |
| Date: | 2005-06-09 05:20:00 |
| Message-ID: | 7209.1118294400@sss.pgh.pa.us |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
"Qingqing Zhou" <zhouqq(at)cs(dot)toronto(dot)edu> writes:
> Yeah, you are right. I scratched elog/ereport(FATAL/PANIC), only found this
> one might be a suspect:
> In _hash_expandtable():
> if (!_hash_try_getlock(rel, start_nblkno, HASH_EXCLUSIVE))
> elog(PANIC, "could not get lock on supposedly new bucket");
> Or maybe elog(PANIC) is a false alarm here?
[ eyes code... ] I think the reason it wants to PANIC is because it's
already hacked up the hash metapage in shared buffers, and it needs
to prevent that update from getting written out. A CRIT_SECTION
would probably be a better answer --- thanks for spotting that.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2005-06-09 05:35:35 | Re: interval->day AdjustIntervalForTypmod? |
| Previous Message | Mark Kirkwood | 2005-06-09 05:12:20 | Re: pg_config --configure ... |