Thread: Time off
Hi everyone, I think I'll be taking some time off from the PostgreSQL project, to work on other stuff that has my interest more at the moment :) I'll still be lurking around, but I won't really have much time to do actual coding. Cheers, Chris
To stop everyone asking me - I will still be working on phpPgAdmin, no need to panic :) Next release of phpPgAdmin should be at the same time as 8.0 PostgreSQL. Chris Christopher Kings-Lynne wrote: > Hi everyone, > > I think I'll be taking some time off from the PostgreSQL project, to > work on other stuff that has my interest more at the moment :) > > I'll still be lurking around, but I won't really have much time to do > actual coding. > > Cheers, > > Chris > > ---------------------------(end of broadcast)--------------------------- > TIP 1: subscribe and unsubscribe commands go to majordomo@postgresql.org
Enjoy the break :) Hints as to the 'other stuff' that is more intersting then PostgreSQL? :) Or is it secret ... ? On Tue, 19 Oct 2004, Christopher Kings-Lynne wrote: > To stop everyone asking me - I will still be working on phpPgAdmin, no need > to panic :) > > Next release of phpPgAdmin should be at the same time as 8.0 PostgreSQL. > > Chris > > Christopher Kings-Lynne wrote: > >> Hi everyone, >> >> I think I'll be taking some time off from the PostgreSQL project, to work >> on other stuff that has my interest more at the moment :) >> >> I'll still be lurking around, but I won't really have much time to do >> actual coding. >> >> Cheers, >> >> Chris >> >> ---------------------------(end of broadcast)--------------------------- >> TIP 1: subscribe and unsubscribe commands go to majordomo@postgresql.org > > ---------------------------(end of broadcast)--------------------------- > TIP 8: explain analyze is your friend > ---- Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: scrappy@hub.org Yahoo!: yscrappy ICQ: 7615664
Marc G. Fournier wrote: > > Enjoy the break :) Hints as to the 'other stuff' that is more > intersting then PostgreSQL? :) Or is it secret ... ? It's probably just a joke. Can you imagine something more interesting than PostgreSQL?!? Regards, Andreas
On 10/19/2004 12:11 PM, Andreas Pflug wrote: > Marc G. Fournier wrote: >> >> Enjoy the break :) Hints as to the 'other stuff' that is more >> intersting then PostgreSQL? :) Or is it secret ... ? > > It's probably just a joke. Can you imagine something more interesting > than PostgreSQL?!? There comes the time in every hackers life when he discovers that even unsuccessfully chasing girls can be more fun than debugging kernel modules or interface libraries. Some get over that phase without greater collateral damage, some become successfull in the chasing, some then get caught by the upgrade policies of this quite different kind of hard- and software, and some even go that far that they experiment with its replication features ... and believe me, it takes a lot of time to get those replicas running :-) Jan > > Regards, > Andreas > > ---------------------------(end of broadcast)--------------------------- > TIP 4: Don't 'kill -9' the postmaster -- #======================================================================# # It's easier to get forgiveness for being wrong than for being right. # # Let's break this rule - forgive me. # #================================================== JanWieck@Yahoo.com #
> > There comes the time in every hackers life when he discovers that even > unsuccessfully chasing girls can be more fun than debugging kernel > modules or interface libraries. Some get over that phase without greater > collateral damage, some become successfull in the chasing, some then get > caught by the upgrade policies of this quite different kind of hard- and > software, and some even go that far that they experiment with its > replication features ... and believe me, it takes a lot of time to get > those replicas running :-) Your telling me and we are not even legally allowed to use them as slaves ;) Sincerely, Joshua D. Drake > > > Jan > > >> >> Regards, >> Andreas >> >> ---------------------------(end of broadcast)--------------------------- >> TIP 4: Don't 'kill -9' the postmaster > > > -- Command Prompt, Inc., home of PostgreSQL Replication, and plPHP. Postgresql support, programming shared hosting and dedicated hosting. +1-503-667-4564 - jd@commandprompt.com - http://www.commandprompt.com Mammoth PostgreSQL Replicator. Integrated Replication for PostgreSQL
Attachment
On Tue, 19 Oct 2004, Jan Wieck wrote: > On 10/19/2004 12:11 PM, Andreas Pflug wrote: > >> Marc G. Fournier wrote: >>> >>> Enjoy the break :) Hints as to the 'other stuff' that is more intersting >>> then PostgreSQL? :) Or is it secret ... ? >> >> It's probably just a joke. Can you imagine something more interesting than >> PostgreSQL?!? > > There comes the time in every hackers life when he discovers that even > unsuccessfully chasing girls can be more fun than debugging kernel > modules or interface libraries. Some get over that phase without greater > collateral damage, some become successfull in the chasing, some then get > caught by the upgrade policies of this quite different kind of hard- and > software, and some even go that far that they experiment with its > replication features ... and believe me, it takes a lot of time to get > those replicas running :-) *rofl* I can definitely relate to this one ... and, assuming that this is an accurate assessment of CKL's current situation ... most heartfelt congratulations to you and yours :) ---- Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: scrappy@hub.org Yahoo!: yscrappy ICQ: 7615664
On Oct 19, 2004, at 2:05 PM, Joshua D. Drake wrote: >> There comes the time in every hackers life when he discovers that >> even unsuccessfully chasing girls can be more fun than debugging >> kernel modules or interface libraries. Some get over that phase >> without greater collateral damage, some become successfull in the >> chasing, some then get caught by the upgrade policies of this quite >> different kind of hard- and software, and some even go that far that >> they experiment with its replication features ... and believe me, it >> takes a lot of time to get those replicas running :-) > > Your telling me and we are not even legally allowed to use them as > slaves ;) > Its also an unusual replication scheme in that, more often than not, the slaves control the masters. > Sincerely, > > Joshua D. Drake > > > >> Jan >>> >>> Regards, >>> Andreas >>> >>> ---------------------------(end of >>> broadcast)--------------------------- >>> TIP 4: Don't 'kill -9' the postmaster > > > -- > Command Prompt, Inc., home of PostgreSQL Replication, and plPHP. > Postgresql support, programming shared hosting and dedicated hosting. > +1-503-667-4564 - jd@commandprompt.com - http://www.commandprompt.com > Mammoth PostgreSQL Replicator. Integrated Replication for PostgreSQL > <jd.vcf> > ---------------------------(end of > broadcast)--------------------------- > TIP 4: Don't 'kill -9' the postmaster > -------------------- Andrew Rawnsley President The Ravensfield Digital Resource Group, Ltd. (740) 587-0114 www.ravensfield.com
>> Enjoy the break :) Hints as to the 'other stuff' that is more >> intersting then PostgreSQL? :) Or is it secret ... ? > > It's probably just a joke. Can you imagine something more interesting > than PostgreSQL?!? www.planeshift.it (Sorry for the sucky flash intro :/) I've been wanting to get into some 3d for a while... Has a MySQL backend unfortunately - maybe I can convert them :) Chris
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > Has a MySQL backend unfortunately - maybe I can convert them :) We might not let you back otherwise! :) - -- Greg Sabino Mullane greg@turnstep.com PGP Key: 0x14964AC8 200410192349 -----BEGIN PGP SIGNATURE----- iD8DBQFBdeDBvJuQZxSWSsgRAozdAJ49WWeoFclbLbh4102x5pebfV/JQwCfSbI9 gOKPqpXD7DfR+Ztrz2Bxwv8= =5f8x -----END PGP SIGNATURE-----
> 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). Cheers, Steve
[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