Skip site navigation (1) Skip section navigation (2)

Re: lock_timeout GUC patch

From: Boszormenyi Zoltan <zb(at)cybertec(dot)at>
To: Jaime Casanova <jcasanov(at)systemguards(dot)com(dot)ec>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-hackers(at)postgresql(dot)org, Robert Haas <robertmhaas(at)gmail(dot)com>, Jeff Janes <jeff(dot)janes(at)gmail(dot)com>, Alvaro Herrera <alvherre(at)commandprompt(dot)com>, Bruce Momjian <bruce(at)momjian(dot)us>, Hans-Juergen Schoenig <postgres(at)cybertec(dot)at>, Josh Berkus <josh(at)agliodbs(dot)com>, Sándor Miglécz <sandor(at)cybertec(dot)at>, Andres Freund <andres(at)anarazel(dot)de>
Subject: Re: lock_timeout GUC patch
Date: 2010-01-13 09:14:12
Message-ID: (view raw or whole thread)
Lists: pgsql-hackers
Jaime Casanova írta:
> 2010/1/13 Boszormenyi Zoltan <zb(at)cybertec(dot)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

In response to


pgsql-hackers by date

Next:From: Zdenek KotalaDate: 2010-01-13 10:11:27
Subject: Deadlock in vacuum (check fails)
Previous:From: Fujii MasaoDate: 2010-01-13 08:47:48
Subject: Re: Streaming replication and non-blocking I/O

Privacy Policy | About PostgreSQL
Copyright © 1996-2015 The PostgreSQL Global Development Group