Re: [PATCH] lock_timeout and common SIGALRM framework - Mailing list pgsql-hackers

From Boszormenyi Zoltan
Subject Re: [PATCH] lock_timeout and common SIGALRM framework
Date
Msg-id 4FE03BF3.1070805@cybertec.at
Whole thread Raw
In response to Re: [PATCH] lock_timeout and common SIGALRM framework  (Alvaro Herrera <alvherre@commandprompt.com>)
Responses Re: [PATCH] lock_timeout and common SIGALRM framework
Re: [PATCH] lock_timeout and common SIGALRM framework
List pgsql-hackers
2012-06-18 19:46 keltezéssel, Alvaro Herrera írta:
> Excerpts from Boszormenyi Zoltan's message of vie may 11 03:54:13 -0400 2012:
>> Hi,
>>
>> another rebasing and applied the GIT changes in
>> ada8fa08fc6cf5f199b6df935b4d0a730aaa4fec to the
>> Windows implementation of PGSemaphoreTimedLock.
> Hi,
>
> I gave the framework patch a look.  One thing I'm not sure about is the
> way you've defined the API.  It seems a bit strange to have a nice and
> clean, generic interface in timeout.h; and then have the internal
> implementation of the API cluttered with details such as what to do when
> the deadlock timeout expires.  Wouldn't it be much better if we could
> keep the details of CheckDeadLock itself within proc.c, for example?

Do you mean adding a callback function argument to for enable_timeout()
would be better?

> Same for the other specific Check*Timeout functions.  It seems to me
> that the only timeout.c specific requirement is to be able to poke
> base_timeouts[].indicator and fin_time.  Maybe that can get done in
> timeout.c and then have the generic checker call the module-specific
> checker.

Or instead of static functions, Check* functions can be external
to timeout.c. It seemed to be a good idea to move all the timeout
related functions to timeout.c.

>    ... I see that you have things to do before and after setting
> "indicator".  Maybe you could split the module-specific Check functions
> in two and have timeout.c call each in turn.  Other than that I don't
> see that this should pose any difficulty.
>
> Also, I see you're calling GetCurrentTimestamp() in the checkers; maybe
> more than once per signal if you have multiple timeouts enabled.

Actually, GetCurrentTimestamp() is not called multiple times,
because only the first timeout source in the queue can get triggered.

>    Maybe
> it'd be better to call it in once handle_sig_alarm and then pass the
> value down, if necessary (AFAICS if you restructure the code as I
> suggest above, you don't need to get the value down the the
> module-specific code).

But yes, this way it can be cleaner.

>
> As for the Init*Timeout() and Destroy*Timeout() functions, they seem
> a bit pointless -- I mean if they just always call the generic
> InitTimeout and DestroyTimeout functions, why not just define the struct
> in a way that makes the specific functions unnecessary?  Maybe you even
> already have all that's necessary ... I think you just change
> base_timeouts[i].timeout_destroy(false); to DestroyTimeout(i, false) and
> so on.

OK, I will experiment with it.

> Minor nitpick: the "Interface:" comment in timeout.c seems useless.
> That kind of thing tends to get overlooked and obsolete over time.  We
> have examples of such things all over the place.  I'd just rip it and
> have timeout.h be the interface documentation.

OK.

> BTW it doesn't seem that datatype/timestamp.h is really necessary in
> timeout.h.

You are wrong. get_timeout_start() returns TimestampTz and it's
defined in datatype/timestamp.h.

Thanks for the review, I will send the new code soon.

Best regards,
Zoltán Böszörményi

--
----------------------------------
Zoltán Böszörményi
Cybertec Schönig & Schönig GmbH
Gröhrmühlgasse 26
A-2700 Wiener Neustadt, Austria
Web: http://www.postgresql-support.de     http://www.postgresql.at/



pgsql-hackers by date:

Previous
From: Dave Page
Date:
Subject: Re: Libxml2 load error on Windows
Next
From: Amit Kapila
Date:
Subject: Re: Allow WAL information to recover corrupted pg_controldata