Re: lock_timeout GUC patch
От | Boszormenyi Zoltan |
---|---|
Тема | Re: lock_timeout GUC patch |
Дата | |
Msg-id | 4B4D6338.9010902@cybertec.at обсуждение исходный текст |
Ответ на | Re: lock_timeout GUC patch (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: lock_timeout GUC patch
Re: lock_timeout GUC patch |
Список | pgsql-hackers |
Tom Lane írta: > Jaime Casanova <jcasanov@systemguards.com.ec> writes: > >> it has a hunk failed when trying to apply i guess it's because of >> Tom's refactor of relcache.c >> > > If this patch is touching those parts of relcache.c, it probably needs > rethinking. > > regards, tom lane > > The reject in my patch is because of this chunk in your change: *************** load_critical_index(Oid indexoid) *** 2836,2842 **** Relation ird; LockRelationOid(indexoid, AccessShareLock); ! ird = RelationBuildDesc(indexoid, NULL); if (ird == NULL) elog(PANIC, "could not open critical system index%u", indexoid); ird->rd_isnailed = true; --- 2893,2899 ---- Relation ird; LockRelationOid(indexoid, AccessShareLock); ! ird = RelationBuildDesc(indexoid, true); if (ird == NULL) elog(PANIC, "could not open critical system index%u", indexoid); ird->rd_isnailed = true; What I did there is to check the return value of LockRelationOid() and also elog(PANIC) if the lock wasn't available. Does it need rethinking? -- Bible has answers for everything. Proof: "But let your communication be, Yea, yea; Nay, nay: for whatsoever is more than these cometh of evil." (Matthew 5:37) - basics of digital technology. "May your kingdom come" - superficial description of plate tectonics ---------------------------------- Zoltán Böszörményi Cybertec Schönig & Schönig GmbH http://www.postgresql.at/
В списке pgsql-hackers по дате отправления: