Обсуждение: 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