| From: | tgl(at)postgresql(dot)org (Tom Lane) |
|---|---|
| To: | pgsql-committers(at)postgresql(dot)org |
| Subject: | pgsql: Fix LOAD_CRIT_INDEX() macro to take out AccessShareLock on the |
| Date: | 2008-04-16 18:23:19 |
| Message-ID: | 20080416182319.2047D7559CC@cvs.postgresql.org |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-committers |
Log Message:
-----------
Fix LOAD_CRIT_INDEX() macro to take out AccessShareLock on the system index
it is trying to build a relcache entry for. This is an oversight in my 8.2
patch that tried to ensure we always took a lock on a relation before trying
to build its relcache entry. The implication is that if someone committed a
reindex of a critical system index at about the same time that some other
backend were starting up without a valid pg_internal.init file, the second one
might PANIC due to not seeing any valid version of the index's pg_class row.
Improbable case, but definitely not impossible.
Tags:
----
REL8_2_STABLE
Modified Files:
--------------
pgsql/src/backend/utils/cache:
relcache.c (r1.250.2.1 -> r1.250.2.2)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/backend/utils/cache/relcache.c?r1=1.250.2.1&r2=1.250.2.2)
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Bruce Momjian | 2008-04-16 20:57:18 | pgsql: Update most recent release to 8.3.1. |
| Previous Message | Tom Lane | 2008-04-16 18:23:12 | pgsql: Fix LOAD_CRIT_INDEX() macro to take out AccessShareLock on the |