Re: Reduced power consumption in autovacuum launcher process

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Peter Geoghegan <peter(at)2ndquadrant(dot)com>
Cc: Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, PG Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Reduced power consumption in autovacuum launcher process
Date: 2011-08-09 22:07:58
Message-ID: 13856.1312927678@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Peter Geoghegan <peter(at)2ndquadrant(dot)com> writes:
> Attached is revision of this patch that now treats the latch in
> PGPROC, waitLatch, as the generic "process latch", rather than just
> using it for sync rep; It is initialised appropriately as a shared
> latch generically, within InitProcGlobal(), and ownership is
> subsequently set within InitProcess(). We were doing so before, though
> only for the benefit of sync rep.

Now that I've got the WaitLatch code fully swapped into my head,
I'm thinking of pushing on to review/commit this patch of Peter's.

> On 18 July 2011 20:06, Heikki Linnakangas
> <heikki(dot)linnakangas(at)enterprisedb(dot)com> wrote:
>> Right, we can easily change the timeout argument to be in milliseconds
>> instead of microseconds.

> I've done so in this latest revision as a precautionary measure. I
> don't see much point in sub-millisecond granularity, and besides, the
> Windows implementation will not provide that granularity anyway as
> things stand.

I did not see any objections to such a change. I think we should pull
out this aspect and commit it to 9.1 as well as HEAD. That will provide
one less gotcha for anyone who develops against the 9.1 latch code and
later needs to port to 9.2.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Geoghegan 2011-08-09 23:25:03 Re: Reduced power consumption in autovacuum launcher process
Previous Message Tom Lane 2011-08-09 21:38:12 Re: Ignore lost+found when checking if a directory is empty