Thread: test geometry ... FAILED
Hi, When I do a make check I see this line in the output: test geometry ... FAILED Should I worry ? If yes, how can I eliminate it ? Thanks ahead, János
=?ISO-8859-1?Q?J=E1nos_L=F6bb?= <janos.lobb@yale.edu> writes: > When I do a > make check > I see this line in the output: > test geometry ... FAILED > Should I worry ? Probably not; the geometry test is prone to platform-specific differences in low-order digits. For more info about regression test interpretation see http://www.ca.postgresql.org/users-lounge/docs/7.2/postgres/regress-evaluation.html Still, we do try to provide exact comparison files for most popular platforms. It'd be interesting to know your exact platform, compiler, PG version, and the specific regression-test diffs. regards, tom lane
hi all, today my server crashes. (syslog see below) i was able to connect to but the machines behaviour was strange. load was above 152. i couldnt stop/kill the postmaster process. ps just hangs in the middle of the processlist. i suspect to optimistic shared memory settings in sysctl.conf for the reason, but i am not shure. anyone has similar experiences or is it a linux/kernel related problem? thanks thilo hille syslog ouput: kernel BUG at page_alloc.c:87! invalid operand: 0000 Kernel 2.4.9-31 CPU: 0 EIP: 0010:[__free_pages_ok+64/784] Not tainted EIP: 0010:[<c012beb4>] Not tainted EFLAGS: 00010286 EIP is at __free_pages_ok [kernel] 0x40 eax: 0000001f ebx: c1cc2a4c ecx: 00000001 edx: 000018a2 esi: c1cc2a4c edi: 00000000 ebp: 00000000 esp: d6aabe78 ds: 0018 es: 0018 ss: 0018 Process postmaster (pid: 26160, stackpage=d6aab000) Stack: c022ede7 00000057 c1cb9080 2cb04007 00400000 0008c000 c0213cac c1cc2a4c c1cc2a4c 00400000 00370000 c012cdcd 0008c000 00000058 00000018 00000018 c1cc2a4c 00000000 c0121b52 c1cc2a4c 00000058 e3fcadc0 00000000 46000000 Call Trace: [IRQ0x0f_interrupt+110759/136192] .rodata.str1.1 [kernel] 0x2042 Call Trace: [<c022ede7>] .rodata.str1.1 [kernel] 0x2042 [call_do_IRQ+5/13] call_do_IRQ [kernel] 0x5 [<c0213cac>] call_do_IRQ [kernel] 0x5 [free_page_and_swap_cache+193/200] free_page_and_swap_cache [kernel] 0xc1 [<c012cdcd>] free_page_and_swap_cache [kernel] 0xc1 [zap_page_range+506/704] zap_page_range [kernel] 0x1fa [<c0121b52>] zap_page_range [kernel] 0x1fa [tcp_close+1360/1372] tcp_close [kernel] 0x550 [<c01dd490>] tcp_close [kernel] 0x550 [do_page_fault+349/1084] do_page_fault [kernel] 0x15d [<c01119c5>] do_page_fault [kernel] 0x15d [do_page_fault+453/1084] do_page_fault [kernel] 0x1c5 [<c0111a2d>] do_page_fault [kernel] 0x1c5 [exit_mmap+176/276] exit_mmap [kernel] 0xb0 [<c01240ac>] exit_mmap [kernel] 0xb0 [mmput+84/108] mmput [kernel] 0x54 [<c01136f8>] mmput [kernel] 0x54 [do_exit+179/492] do_exit [kernel] 0xb3 [<c0117707>] do_exit [kernel] 0xb3 [filp_close+78/88] filp_close [kernel] 0x4e [<c013198a>] filp_close [kernel] 0x4e [do_page_fault+0/1084] do_page_fault [kernel] 0x0 [<c0111868>] do_page_fault [kernel] 0x0 [system_call+51/56] system_call [kernel] 0x33 [<c0106e0f>] system_call [kernel] 0x33 Code: 0f 0b 5d 58 89 d8 2b 05 ac ad 31 c0 8d 04 40 8d 04 80 89 c2
hi! i can access the first 100 records by this command: => select * from foo_table limit 100; OR => select * from foo_table order by foo_column desc limit 100; how do i access the next 100 records without having the first 100 displayed? thanks! mel
Mel, > => select * from foo_table limit 100; > OR > => select * from foo_table order by foo_column desc limit 100; Easy: SELECT * FROM foo_table LIMIT 100 OFFSET 100; -Josh Berkus
On Wed, 2002-10-16 at 05:10, Josh Berkus wrote: > Mel, > > > => select * from foo_table limit 100; > > OR > > => select * from foo_table order by foo_column desc limit 100; > > Easy: > > SELECT * FROM foo_table LIMIT 100 OFFSET 100; > > -Josh Berkus If the query is complex and time-consuming, you might do better to use a cursor; then the query is done once and you can fetch results from it at will. Using LIMIT and OFFSET requires the whole query to run every time. If you are running it in response to an interactive request for the next chunk of data, the necessary delay is obviously undesirable. (Another problem, if you are not in a transaction, is that rows may be added or deleted by other sessions in between your commands, which may cause gaps or duplications in the records you see) Use a cursor like this: BEGIN; -- cursors must operate in a transaction DECLARE mycursor CURSOR FOR SELECT * FROM complex_view; FETCH 100 FROM mycursor; -- first 100 rows FETCH 100 FROM mycursor; -- next 100 FETCH NEXT FROM mycursor; -- next row FETCH BACKWARD 10 FROM mycursor; -- previous 10 rows (reversed) END; -- end transaction and close cursor -- Oliver Elphick Oliver.Elphick@lfix.co.uk Isle of Wight, UK http://www.lfix.co.uk/oliver GPG: 1024D/3E1D0C1C: CA12 09E0 E8D5 8870 5839 932A 614D 4C34 3E1D 0C1C ======================================== "But be ye doers of the word, and not hearers only, deceiving your own selves." James 1:22