Re: Time off

From: Lamar Owen <lowen(at)pari(dot)edu>
To: Steve Crawford <scrawford(at)pinpointresearch(dot)com>
Cc: PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Time off
Date: 2004-10-24 03:21:12
Message-ID: 200410232321.12848.lowen@pari.edu
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

[late on a Saturday night, getting ready to go to bed, after putting four to
bed: this topic is just too good to pass on....apologies in advance...]

On Saturday 23 October 2004 17:16, Steve Crawford wrote:
> > Its also an unusual replication scheme in that, more often than
> > not, the slaves control the masters.

> As the slave of a replica with an 86 day 16 hour uptime I've also
> discovered that the new I/O functions take some adjustment as does
> working around the lack of sleep(3).

The 9 month bootstrap time does cause some interesting latency issues, not to
mention the nondeterministic behavior and unpredictable endianess of the
processors that can cause the controlling init to fallback to heuristic
techniques of initing processes in parallel, out-of-order, speculative,
deeply and randomly pipelined manners. INTERCAL is easier to program than
the machine code of these replicas. Forget the trampolines of COME-FROM.
You get the wonders of ME-TOO and HE-DID_IT. Endless loops of
DID-TO::DID_NOT require the deepest programming discipline, and sometimes a
nonmaskable interrupt, to break. But the WHY loop is the most difficult,
since the degree of precision of the controlling conditional constantly and
randomly changes.

But very few programming tasks are more rewarding than bringing this NDIA of
the last order to code maturity, and even to version 2.0. Process migration
issues abound, but are necessary for proper process stability. The
controlling init process pair often has difficulty free'ing malloc'ed
resources while migrating child processes. Inevitable memory leaks occur,
with free'ed resources never equalling malloc'ed ones. But when the replica
forks, and spawns its own child process, resource utilization goes up; but
fortunately the VM code can easily swap back to the home of the originating
processes.

Here with four, one big endian with an 10y26w5d5h41m uptime, one little endian
with 9y27w6d21h37m, one little endian at 7y7w2d22h14m, and one little endian
2y2w1d4h56m (due to kernel/init spawn events, uptime resolutions of less than
a minute are difficult, if not impossible, to determine due to time dilation
effects at kernel-initprocess handoff, where the spawning init loses
timeslices during replica kernel respawn.). Endian conflicts abound, but
uptime-related conflicts abound more, with significant replica competition
for init process timeslices; all such attempts typically require superuser
intervention to re-nice.

*ducking*and*grinning*
--
Lamar Owen
Director of Information Technology
Pisgah Astronomical Research Institute
1 PARI Drive
Rosman, NC 28772
(828)862-5554
www.pari.edu

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Curt Sampson 2004-10-24 05:46:16 Re: First set of OSDL Shared Mem scalability results, some
Previous Message Tom Lane 2004-10-24 03:20:04 Dumb shlib build rules cause regression test failures on ia64