| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
| Cc: | Boszormenyi Zoltan <zb(at)cybertec(dot)at>, Alvaro Herrera <alvherre(at)commandprompt(dot)com>, Marc Cousin <cousinmarc(at)gmail(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org>, Hans-Juergen Schoenig <hs(at)cybertec(dot)at>, Ants Aasma <ants(at)cybertec(dot)at> |
| Subject: | Re: [PATCH] lock_timeout and common SIGALRM framework |
| Date: | 2012-06-26 13:38:29 |
| Message-ID: | 4871.1340717909@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> On Tue, Jun 26, 2012 at 8:03 AM, Boszormenyi Zoltan <zb(at)cybertec(dot)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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Robert Haas | 2012-06-26 13:48:37 | Re: Catalog/Metadata consistency during changeset extraction from wal |
| Previous Message | Tom Lane | 2012-06-26 13:25:04 | Re: new --maintenance-db options |