On Wed, Aug 10, 2011 at 3:08 PM, Tom Lane wrote:
> Peter Geoghegan writes:
>> On 10 August 2011 01:35, Tom Lane wrote:
>>> Actually, I'm nearly done with it already. Perhaps you could start
>>> thinking about the other polling loops.
>
>> Fair enough. I'm slightly surprised that there doesn't n
Peter Geoghegan 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
> subs
Peter Geoghegan writes:
> On 10 August 2011 01:35, Tom Lane wrote:
>> Actually, I'm nearly done with it already. Perhaps you could start
>> thinking about the other polling loops.
> Fair enough. I'm slightly surprised that there doesn't need to be some
> bikeshedding about my idea to treat the
On 10 August 2011 01:35, Tom Lane wrote:
> Actually, I'm nearly done with it already. Perhaps you could start
> thinking about the other polling loops.
Fair enough. I'm slightly surprised that there doesn't need to be some
bikeshedding about my idea to treat the PGPROC latch as the generic,
per-
Peter Geoghegan writes:
> On 9 August 2011 23:07, Tom Lane wrote:
>> 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.
> Thanks for giving this your attention. I had already planned to
> produce a new revision t
On 9 August 2011 23:07, Tom Lane wrote:
> 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.
Thanks for giving this your attention. I had already planned to
produce a new revision this weekend, so I'd appreciate it
Peter Geoghegan 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
> subs
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().
On 18 July 2011 20:06, Heikki Linnakangas
wrote:
>> Hmm. Well, it's not too late to rethink the WaitLatch API, if we think
>> that that might be a significant limitation.
>
> Right, we can easily change the timeout argument to be in milliseconds
> instead of microseconds.
+1
--
Peter Geoghegan
On Mon, Jul 18, 2011 at 3:28 PM, k...@rice.edu wrote:
> On Mon, Jul 18, 2011 at 03:12:20PM -0400, Tom Lane wrote:
>> Heikki Linnakangas writes:
>> > On 18.07.2011 18:32, Tom Lane wrote:
>> >> Hmm. Well, it's not too late to rethink the WaitLatch API, if we think
>> >> that that might be a signif
On Mon, Jul 18, 2011 at 03:12:20PM -0400, Tom Lane wrote:
> Heikki Linnakangas writes:
> > On 18.07.2011 18:32, Tom Lane wrote:
> >> Hmm. Well, it's not too late to rethink the WaitLatch API, if we think
> >> that that might be a significant limitation.
>
> > Right, we can easily change the time
Heikki Linnakangas writes:
> On 18.07.2011 18:32, Tom Lane wrote:
>> Hmm. Well, it's not too late to rethink the WaitLatch API, if we think
>> that that might be a significant limitation.
> Right, we can easily change the timeout argument to be in milliseconds
> instead of microseconds.
On the
On 18.07.2011 18:32, Tom Lane wrote:
Robert Haas writes:
On Mon, Jul 18, 2011 at 10:35 AM, Tom Lane wrote:
A wakeup once every half hour would surely not be an issue from a power
consumption standpoint. However, I'm not sure I understand here: aren't
we trying to remove the timeouts complete
Robert Haas writes:
> On Mon, Jul 18, 2011 at 10:35 AM, Tom Lane wrote:
>> A wakeup once every half hour would surely not be an issue from a power
>> consumption standpoint. However, I'm not sure I understand here: aren't
>> we trying to remove the timeouts completely?
> Well, in the case of th
On Mon, Jul 18, 2011 at 10:35 AM, Tom Lane wrote:
> Robert Haas writes:
>> On Mon, Jul 18, 2011 at 9:12 AM, Peter Geoghegan
>> wrote:
>>> There could perhaps be a very large "nap", as determined by
>>> launcher_determine_sleep(), so that the total number of microseconds
>>> passed to WaitLatch(
Robert Haas writes:
> On Mon, Jul 18, 2011 at 9:12 AM, Peter Geoghegan
> wrote:
>> There could perhaps be a very large "nap", as determined by
>> launcher_determine_sleep(), so that the total number of microseconds
>> passed to WaitLatch() would exceed the maximum long size that can be
>> safely
On Mon, Jul 18, 2011 at 9:12 AM, Peter Geoghegan wrote:
>>> Another concern is, what happens when we receive a signal, generically
>>> handled or otherwise, and have to SetLatch() to avoid time-out
>>> invalidation? Should we just live with a spurious
>>> AutoVacLauncherMain() iteration, or should
On Jul18, 2011, at 15:12 , Peter Geoghegan wrote:
> struct timeval is comprised of two longs - one representing seconds,
> and the other represented the balance of microseconds. Previously, we
> didn't combine them into a single microsecond representation. Now, we
> do.
I haven't actually looked a
On 18 July 2011 01:48, Robert Haas wrote:
> Might be good to start a new thread for each auxilliary process, or we
> may get confused.
Right - I've done so in this reply. There isn't a problem as such with
the AV Launcher patch - there's a problem with most or all remaining
auxiliary processes, t
19 matches
Mail list logo
