Re: subversion vs cvs (Was: Re: [HACKERS] linked list rewrite)
Dustin Sallings wrote: You can use distributed revision control systems as centralized systems, but not vice-versa. Not true, the other way around exists, that is what svk does. As far as understanding the simplicity of arch (if you wanted to understand the problems it solves and implement it yourself), a really good presentation was posted today to the arch list that sums it up quickly and concisely. It's hard to go through that and not think, ``I could write this.'' http://web.verbum.org/tla/grokking-arch/grokking-arch.html Will read it, thanks. Regards, Magnus ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: subversion vs cvs (Was: Re: [HACKERS] linked list rewrite)
Christopher Kings-Lynne wrote: What's needed is a good window client like WinCVS, however... Chris There is a number of those, our shop uses (and makes programs for) both windows and unix (and might soon use mac's aswell), so it's very important that there exists a good client for each. Especially if you version html pages and such that is edited by people that isn't so techy. We're using TortoiseSvn right now, it's implemented as an explorer extension, so you just rightclick on a file or directory to update/commit/whatever. What i like with svn is that it's a nobrainer for old cvs guys like me to use it. It solves all the problems with CVS right now, and promises more features later on (like much better than CVS merging). The new buzz is distributed versioning systems these days, but i question if that is called for in the vast majority of projects out there. If the only reason is for offline work that can be achieved with subversion too, with svk for example (haven't tried it, but been told that it works fine). Svk handles or will(?) handle distributed repos in the bk sense aswell, i believe. But ofcourse arch has alot of features that are extremly cool, the reason why i didn't evaluate it further was that it didn't work on windows well, the fixed weird branching/version naming and the complexity of learning for our developers since they already use cvs. Surely the two systems should be evaluated against their competiors within the same distribution models, not cross the boundries, since the design is very different. Subversions strength is it's percieved simplicity, and archs strength is it's complexity. Regards, Magnus ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] PostgreSQL 7.3.4 gets killed by SIG_KILL [SOLVED]
Jeff wrote: Do you have any system monitoring scripts that may be killing it as it may look like a runaway process? We've had this happen to us before. You tend to forget about things like that. This got me thinking, and i rechecked all possibilities. It turned out that we changed rlimit policies earlier and the default cpu time limits bleeded over to postgres since it didn't have a negating entry in the pam limits control. Since the startup scripts use su - postgres -c cmd it logged in and so got the now default cpu time values. So it was only a mindbug, and thats good :) Magnus ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
[HACKERS] PostgreSQL 7.3.4 gets killed by SIG_KILL
I have this big table running on an old linux install (kernel 2.2.25). I've COPYed some tcpip logs into a table created as such: create table ipstats (time timestamp, src inet, dst inet, npackets int8, nbytes int8); Big: select count(*) from ipstats; count -- 99173733 When i do two selects some from that table multiple times, the the backend doing the selects is getting killed by signal 9. The select pair look like: select sum(nbytes) from ipstats where dst = '10.10.10.170'; select sum(nbytes) from ipstats where src = '10.10.10.170'; This is what the serverlog says: LOG: server process (pid 20308) was terminated by signal 9 LOG: terminating any other active server processes LOG: all server processes terminated; reinitializing shared memory and semaphores FATAL: The database system is starting up LOG: database system was interrupted at 2003-12-03 23:21:49 CET FATAL: The database system is starting up LOG: checkpoint record is at 3/9095BC20 LOG: redo record is at 3/9095BC20; undo record is at 0/0; shutdown TRUE LOG: next transaction id: 8716399; next oid: 141842933 LOG: database system was not properly shut down; automatic recovery in progress LOG: ReadRecord: record with zero length at 3/9095BC60 LOG: redo is not required LOG: database system is ready When i attach a gdb to the process it doesn't help, it exits immediatly anyways. This i believe is because SIG_KILL is unstoppable... Any ideas as of what to do? Regards Magnus ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] PostgreSQL 7.3.4 gets killed by SIG_KILL
Doug McNaught wrote: Magnus Naeslund(t) [EMAIL PROTECTED] writes: I have this big table running on an old linux install (kernel 2.2.25). I've COPYed some tcpip logs into a table created as such: Linux is probably killing your process because it (the kernel) is low on memory. Unfortunately, this happens more often with older versions of the kernel. Add more RAM/swap or figure out how to make your query use less memory... -Doug Well this just isn't the case. There is no printout in kernel logs/dmesg (as it would be if the kernel killed it in an OOM situation). I have 1 GB of RAM, and 1.5 GB of swap (swap never touched). When running the query i have about 850 MB sitting in kernel cache, the postgres process takes about 40MB of memory, and the ipcs -m command shows that postgresql is taking 41508864 bytes of shared memory. There is no sorting or index lookups going on, the query is simple. I just had an power outage, i'll check if it maybe wised up after reboot or something, but i doubt it. Is it possible to somehow find out what process sent the KILL (or if it's the kernel) ? I find this very weird to say the least... Magnus ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
