lock_timeout GUC patch
in [PgSql]
|
From: Tom Lane on 13 Jan 2010 00:11 Jaime Casanova <jcasanov(a)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 -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Boszormenyi Zoltan on 13 Jan 2010 01:07 Tom Lane �rta: > Jaime Casanova <jcasanov(a)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/ -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Jaime Casanova on 13 Jan 2010 01:14 2010/1/13 Boszormenyi Zoltan <zb(a)cybertec.at>: > Tom Lane Ãrta: >> >> If this patch is touching those parts of relcache.c, it probably needs >> rethinking. >> > > What I did there is to check the return value of LockRelationOid() the hunk was because a diference in the position (i guess patch accept a hunk of reasonable size, assuming there is something like a reasonable size for that) and is not touching the same as your refactor (sorry if i explain myself bad) > and also elog(PANIC) if the lock wasn't available. > Does it need rethinking? > well, i actually think that PANIC is too high for this... -- Atentamente, Jaime Casanova Soporte y capacitación de PostgreSQL AsesorÃa y desarrollo de sistemas Guayaquil - Ecuador Cel. +59387171157 -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Boszormenyi Zoltan on 13 Jan 2010 04:14 Jaime Casanova írta: > 2010/1/13 Boszormenyi Zoltan <zb(a)cybertec.at>: > >> Tom Lane írta: >> >>> If this patch is touching those parts of relcache.c, it probably needs >>> rethinking. >>> >>> >> What I did there is to check the return value of LockRelationOid() >> > > the hunk was because a diference in the position (i guess patch accept > a hunk of reasonable size, assuming there is something like a > reasonable size for that) > > and is not touching the same as your refactor (sorry if i explain myself bad) > > >> and also elog(PANIC) if the lock wasn't available. >> Does it need rethinking? >> >> > > well, i actually think that PANIC is too high for this... > Well, it tries to lock and then open a critical system index. Failure to open it has PANIC, it seemed appropriate to use the same error level if the lock failure case. Best regards, Zoltán Böszörményi -- 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/ -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Boszormenyi Zoltan on 13 Jan 2010 07:07
Jaime Casanova írta: > 2010/1/13 Boszormenyi Zoltan <zb(a)cybertec.at>: > >> Tom Lane írta: >> >>> If this patch is touching those parts of relcache.c, it probably needs >>> rethinking. >>> >>> >> What I did there is to check the return value of LockRelationOid() >> > > the hunk was because a diference in the position (i guess patch accept > a hunk of reasonable size, assuming there is something like a > reasonable size for that) > Actually the reject was not because of the position difference, Tom's refactor changed one line in load_critical_index(): - ird = RelationBuildDesc(indexoid, NULL); + ird = RelationBuildDesc(indexoid, true); -- 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/ -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers |