Horton

Re: [PATCH] lock_timeout and common SIGALRM framework

Tom Lane <tgl@sss.pgh.pa.us>

View thread
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Robert Haas <robertmhaas@gmail.com>
Cc: Boszormenyi Zoltan <zb@cybertec.at>, Alvaro Herrera <alvherre@commandprompt.com>, Marc Cousin <cousinmarc@gmail.com>, Pg Hackers <pgsql-hackers@postgresql.org>, Hans-Juergen Schoenig <hs@cybertec.at>, Ants Aasma <ants@cybertec.at>
Date: 2012-06-26T13:38:29Z
Lists: pgsql-hackers

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. Fix Windows implementation of PGSemaphoreLock.

Robert Haas <robertmhaas@gmail.com> writes:
> On Tue, Jun 26, 2012 at 8:03 AM, Boszormenyi Zoltan <zb@cybertec.at> wrote:
>> I know, but it doesn't feel right to "register" static functionality.

> We do it elsewhere.  The overhead is pretty minimal compared to other
> things we already do during startup, and avoiding the need for the
> array to have a fixed-size seems worth it, IMHO.

It's not even clear that the array needs to be dynamically resizable (yet).
Compare for instance syscache invalidation callbacks, which have so far
gotten along fine with a fixed-size array to hold registrations.  It's
foreseeable that we'll need something better someday, but that day
hasn't arrived, and might never arrive.

I agree with the feeling that this patch isn't done if the "core"
timeout code has to know specifically about each usage.  We have that
situation already.

			regards, tom lane