Re: Time off - Mailing list pgsql-hackers

From Lamar Owen
Subject Re: Time off
Date
Msg-id 200410232321.12848.lowen@pari.edu
Whole thread Raw
In response to Re: Time off  (Steve Crawford <scrawford@pinpointresearch.com>)
List 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


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Dumb shlib build rules cause regression test failures on ia64
Next
From: Dennis Bjorklund
Date:
Subject: Re: Proposed TODO: CREATE .... WITH OWNER;