Horton
Menu

Re: lock_timeout GUC patch

Boszormenyi Zoltan <zb@cybertec.at>

View thread
From: Boszormenyi Zoltan <zb@cybertec.at>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Jaime Casanova <jcasanov@systemguards.com.ec>, pgsql-hackers@postgresql.org, Robert Haas <robertmhaas@gmail.com>, Jeff Janes <jeff.janes@gmail.com>, Alvaro Herrera <alvherre@commandprompt.com>, Bruce Momjian <bruce@momjian.us>, Hans-Juergen Schoenig <postgres@cybertec.at>, Josh Berkus <josh@agliodbs.com>, Sándor Miglécz <sandor@cybertec.at>, Andres Freund <andres@anarazel.de>
Date: 2010-01-13T06:07:52Z
Lists: 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/