Re: Fwd: Re: [HACKERS] Shared memory for RH Linux 7.1
On Thu, 24 May 2001, Ryan Mahoney wrote: > >This is true. You can adjust the value in the /proc/sys/kernel/shmmax > >file. If you change the value it will be reset when you reboot, so you > >will need to write a start-up script to always change this value if you > >want it to be permanent. or you can let sysctl do it with this in /etc/sysctl.conf: kernel.shmmax = 268435456 (obviously changing the value with what is appropriate for your machine). This is for a RH 6.2 box. DOnt know if its the same on 7.1. We switched to FreeBSD between redhat 6.2 and 7.0, so we dont have any RH7.1 boxes laying around. I suspect it hasn't changed though. Mike ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] The lightbulb just went on...
Tom: I think I may have been seeing this problem as well. We were getting crashes very often with 7.0.2 during VACUUM's if activity was going on to our database during the vacuum (even though the activity was light). Our solution in the meantime was to simply disable the aplications during a vacuum to avoid any activity during hte vacuum, and we have not had a crash on vacuum since that happened. If this sounds consistent with the problem you think Alfred is having, then I would be willing to test your patch on our system as well. If you think it would help, feel free to send me the patch and I will do some testing on it for you. Thanks. Mike On Mon, 16 Oct 2000, Tom Lane wrote: > ... with a blinding flash ... > > The VACUUM funnies I was complaining about before may or may not be real > bugs, but they are not what's biting Alfred. None of them can lead to > the observed crashes AFAICT. ...
Re: [HACKERS] The lightbulb just went on...
On Tue, 17 Oct 2000, Tom Lane wrote: > > and we have not had a crash on vacuum since that happened. If this > > sounds consistent with the problem you think Alfred is having, > > Yes, it sure does. > > The patch I have applies atop a previous change in the REL7_0_PATCHES > branch, so what I would recommend is that you pull the current state of > the REL7_0_PATCHES branch from our CVS server, and then you can test > what will shortly become 7.0.3. There are several other critical bug > fixes in there since 7.0.2. Hi Tom. I have built from the REL7_0_PATCHES tree yesturday and did some testing on the database. So far no crashes during vacuum like I had been seeing with 7.0.2 :). I am seeing a different problem (and I have seen this with 7.0.2 as well). If I run vacuum, sometimes this error pops up in the client appliction during the vacuum: ERROR: RelationClearRelation: relation 1668325 modified while in use relation 1668325 is a view named "sessions". what happens to sessions is that it does: SELECT session_data, id FROM sessions WHERE id = ? FOR UPDATE client does some processing ... UPDATE sesssions set session_data = ? WHERE id = ?; (this is where the error happens) I think part of my problem might be that sessions is a view and not a table, but it is probably a bug that needs to be noted nonetheless. I am going to try converting "sessions" to a view and see if I can reproduce it that way. Mike
Re: AW: [HACKERS] The lightbulb just went on...
On Thu, 19 Oct 2000, Tom Lane wrote: > Zeugswetter Andreas SB <[EMAIL PROTECTED]> writes: > >> SELECT session_data, id > >> FROM sessions > >> WHERE id = ? > >> FOR UPDATE > >> > >> I think part of my problem might be that sessions is a view > >> and not a table, > > > Did you create an on update do instead rule ? Yes actually :). But Ive since elimintated the rule and figured out I could get the equivalent functionality I was getting the the RULE/VIEW by just using a simple PL/pgSQL trigger. Since doing that, the "relation X modified while in use" errors have gone away, but I'm still not sure I trust VACUUM ANALYZE enough to run it on a non-idle production database :). I want to do more testing before I get that brave :). Mike
[HACKERS] 7.0.2 crash (maybe linux kernel bug??)
Hi. Ive had a crash in postgresql 7.0.2. Looking at what happened, I actually suspect that this is a filesystem bug, and not a postgresql bug necessarily, but I wanted to report it here and see if anyone else had any opinions. The platform this happened on was linux (redhat 6.2), kernel 2.2.16 (SMP) dual pentium III 500MHz cpus, Mylex DAC960 raid controller running in raid5 mode. During regular activity, I got a kernel oops. Looking at the call trace from the kernel, as well as the EIP, I think maybe there is a bug here int the fs buffer code, and that htis is a linux kernel problem (not a postgresql problem). Bug I'm no expert here.. Does this sould correct looking at the kernel erros below? Sorry if this is off topic. I just want to make sure this is a kernel bug and not a postgresql bug. Mike The oopses: kernel: Unable to handle kernel NULL pointer dereference at virtual address 0134 kernel: current->tss.cr3 = 1a325000, %%cr3 = 1a325000 kernel: *pde = kernel: Oops: 0002 kernel: CPU:0 kernel: EIP:0010:[remove_from_queues+169/328] kernel: EFLAGS: 00010206 kernel: eax: 0100 ebx: 0002 ecx: df022e40 edx: efba76b8 kernel: esi: df022e40 edi: ebp: esp: da327ea4 kernel: ds: 0018 es: 0018 ss: 0018 kernel: Process postmaster (pid: 11527, process nr: 51, stackpage=da327000) kernel: Stack: df022e40 c012be79 df022e40 df022e40 1000 c0142cb8 c0142cc7 df022e40 kernel:ec247140 ffea ec0b026c da326000 df022e40 df022e40 df022e40 000a4000 kernel: da327f08 eff29200 1000 00a5 000a5000 kernel: Call Trace: [refile_buffer+77/184] [ext2_file_write+996/1584] [ext2_file_write+1011/1584] [kfree_skbmem+51/64] [__kfree_skb+162/168] [lockd:__insmod_lockd_O/lib/modules/2.2.16-3smp/fs/lockd.o_M394EA7+-76392/76] [handle_IRQ_event+90/140] kernel:[sys_write+240/292] [ext2_file_write+0/1584] [system_call+52/56] [startup_32+43/164] kernel: Code: 89 50 34 c7 01 00 00 00 00 89 02 c7 41 34 00 00 00 00 ff 0d kernel: Unable to handle kernel NULL pointer dereference at virtual address 0100 kernel: current->tss.cr3 = 1ba46000, %%cr3 = 1ba46000 kernel: *pde = kernel: Oops: kernel: CPU:1 kernel: EIP:0010:[find_buffer+104/144] kernel: EFLAGS: 00010206 kernel: eax: 0100 ebx: 0007 ecx: 00069dae edx: 0100 kernel: esi: 000d edi: 3006 ebp: 0005ce4b esp: e53a19f4 kernel: ds: 0018 es: 0018 ss: 0018 kernel: Process postmaster (pid: 5545, process nr: 37, stackpage=e53a1000) kernel: Stack: 0005ce4b 3006 00069dae c012b953 3006 0005ce4b 1000 c012bcc6 kernel:3006 0005ce4b 1000 3006 eff29200 3006 4e4b ef18c960 kernel:c0141ee7 3006 0005ce4b 1000 0005ce4b e53a1bb0 edc3c660 edc3c660 kernel: Call Trace: [get_hash_table+23/36] [getblk+30/324] [ext2_new_block+2291/2756] [getblk+271/324] [ext2_alloc_block+344/356] [block_getblk+305/624] [ext2_getblk+256/524] kernel:[ext2_file_write+1308/1584] [__brelse+19/84] [permission+36/248] [dump_seek+53/104] [dump_seek+53/104] [dump_write+48/84] [elf_core_dump+3104/3216] [do_IRQ+82/92] kernel:[tcp_write_xmit+407/472] [__release_sock+36/124] [tcp_do_sendmsg+2125/2144] [inet_sendmsg+0/144] [cprt+1553/20096] [cprt+1553/20096] [cprt+1553/20096] [do_signal+458/724] kernel:[force_sig_info+168/180] [force_sig+17/24] [do_general_protection+54/160] [error_code+45/52] [signal_return+20/24] kernel: Code: 8b 00 39 6a 04 75 15 8b 4c 24 20 39 4a 08 75 0c 66 39 7a 0c
Re: [HACKERS] Upper limit on number of buffers?
On Sun, 24 Dec 2000, Joe Conway wrote: > Linux > > The default shared memory limit (both SHMMAX and SHMALL) is 32 MB in 2.2 > kernels, but it can be changed in the proc file system (without reboot). For > example, to allow 128 MB: > > $ echo 134217728 >/proc/sys/kernel/shmall > $ echo 134217728 >/proc/sys/kernel/shmmax > You could put these commands into a script run at boot-time. On redhat 6.2 I know that you can use /etc/sysctl.conf to do this as well. Just add this to /etc/sysctl.conf. kernel.shmall = 134217728 kernel.shmmax = 134217728 After this, your tunables will be restored every time that the system boots. Mike
Re: [HACKERS] Re: Beta2 ... ?
On Fri, 5 Jan 2001, Tom Lane wrote: > Lamar Owen <[EMAIL PROTECTED]> writes: > > I am inclined to wait until a Release Candidate, if we have one this go > > around, is available before releasing RPM's, but my mind can be > > changed :-) > > Please do make beta RPMs available. Seems to me that there's a > fair-size population of potential beta testers that we're shutting > out of the process if we don't put out RPMs. Losing available beta > testing work is not a good project management practice ... FWIW: We would definately beta test 7.1 beta releases on our test machines if RPMS were made available. However, if rpms are not made available, its unlikely that anyone around here will get time to build the sources from scratch. So you can count me as one beta tester that you would have if you made RPMS of the betas. Regards, Mike
Re: [HACKERS] Re: Beta2 ... ?
On Wed, 10 Jan 2001, Peter Eisentraut wrote: > Michael J Schout writes: > > > We would definately beta test 7.1 beta releases on our test machines if RPMS > > were made available. However, if rpms are not made available, its unlikely > > that anyone around here will get time to build the sources from scratch. > > Building from source takes five minutes. Reading the installation > instructions takes maybe ten minutes. Don't tell me you don't have that > amount of time but you still want to beta test. *shrug* Yes, building the sources isn't that difficult, but it definately takes longer than: rpm -ivh ftp://ftp.postgresql/pub/whatever/postgresql-\*.rpm My feeling is that if we can make it as easy as possible for beta testers to get the beta releases up and running, the more likely they are to use the beta releases. Mike
