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

From Tom Lane
Subject Re: [PATCH] lock_timeout and common SIGALRM framework
Date
Msg-id 4871.1340717909@sss.pgh.pa.us
Whole thread Raw
In response to Re: [PATCH] lock_timeout and common SIGALRM framework  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
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


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: new --maintenance-db options
Next
From: Robert Haas
Date:
Subject: Re: Catalog/Metadata consistency during changeset extraction from wal