Re: lock_timeout GUC patch - Mailing list pgsql-hackers

From Tom Lane
Subject Re: lock_timeout GUC patch
Date
Msg-id 10386.1263394618@sss.pgh.pa.us
Whole thread Raw
In response to Re: lock_timeout GUC patch  (Boszormenyi Zoltan <zb@cybertec.at>)
Responses Re: lock_timeout GUC patch
List pgsql-hackers
Boszormenyi Zoltan <zb@cybertec.at> writes:
> 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()
> and also elog(PANIC) if the lock wasn't available.
> Does it need rethinking?

Yes.  What you have done is to change all the LockSomething primitives
from return void to return bool and thereby require all call sites to
check their results.  This is a bad idea.  There is no way that you can
ensure that all third-party modules will make the same change, meaning
that accepting this patch will certainly introduce nasty, hard to
reproduce bugs.  And what's the advantage?  The callers are all going
to throw errors anyway, so you might as well do that within the Lock
function and avoid the system-wide API change.

I think this is a big patch with a small patch struggling to get out.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Jaime Casanova
Date:
Subject: Re: lock_timeout GUC patch
Next
From: Robert Haas
Date:
Subject: Re: Bloom index