Обсуждение: [ADMIN] Running Postgres on a HP-Ux 10.10 System
Hello everybody,
I trying to run PostgreSQL 6.4 (or 6.4.2) on a HP-Ux 10.10. The
problem is that the backend process is dieing after two SQL errors.
When I do the following the backend will die:
psql test
=> SALACT * FROM test;
Error ....
=> SALACT * FROM test;
Error ....
Well nobody is using a database in this way nevertheless I feel that
my something in my system is not configured the way it should be.
I tried to compile version 6.4 and 6.4.2 either with gcc 2.7.2.3 and
2.8.1. The result is the same.
The exit code of the backend process is 138.
Any help welcome.
Reiner Nippes
UMS GmbH, Ulm - Germnay
From the log file:
ProcessQuery
CommitTransactionCommand
StartTransactionCommand
ERROR: pg_atoi: error in "34.5": can't parse ".5"
AbortCurrentTransaction
StartTransactionCommand
query: INSERT INTO INT2_TBL(f1) VALUES ('32767');
ProcessQuery
CommitTransactionCommand
StartTransactionCommand
query: INSERT INTO INT2_TBL(f1) VALUES ('-32767');
ProcessQuery
CommitTransactionCommand
StartTransactionCommand
ERROR: pg_atoi: error reading "100000": Result too large
AbortCurrentTransaction
/data/app/postgres/bin/postmaster: reaping dead processes...
/data/app/postgres/bin/postmaster: CleanupProc: pid 17725 exited with status 138
/data/app/postgres/bin/postmaster: CleanupProc: reinitializing shared memory and semaphores
shmem_exit(0) [#0]
Hi,
I don't know about the crashes, but try using 'SELECT'
instead of 'SALACT' (where the hell did you get *that*
from??).
Maarten
> I trying to run PostgreSQL 6.4 (or 6.4.2) on a HP-Ux 10.10. The
> problem is that the backend process is dieing after two SQL errors.
> When I do the following the backend will die:
>
> psql test
> => SALACT * FROM test;
> Error ....
> => SALACT * FROM test;
> Error ....
>
> Well nobody is using a database in this way nevertheless I feel that
> my something in my system is not configured the way it should be.
>
> I tried to compile version 6.4 and 6.4.2 either with gcc 2.7.2.3 and
> 2.8.1. The result is the same.
>
> The exit code of the backend process is 138.
>
> Any help welcome.
>
> Reiner Nippes
> UMS GmbH, Ulm - Germnay
>
> >From the log file:
> ProcessQuery
> CommitTransactionCommand
> StartTransactionCommand
> ERROR: pg_atoi: error in "34.5": can't parse ".5"
> AbortCurrentTransaction
> StartTransactionCommand
> query: INSERT INTO INT2_TBL(f1) VALUES ('32767');
> ProcessQuery
> CommitTransactionCommand
> StartTransactionCommand
> query: INSERT INTO INT2_TBL(f1) VALUES ('-32767');
> ProcessQuery
> CommitTransactionCommand
> StartTransactionCommand
> ERROR: pg_atoi: error reading "100000": Result too large
> AbortCurrentTransaction
> /data/app/postgres/bin/postmaster: reaping dead processes...
> /data/app/postgres/bin/postmaster: CleanupProc: pid 17725 exited with status 138
> /data/app/postgres/bin/postmaster: CleanupProc: reinitializing shared memory and semaphores
> shmem_exit(0) [#0]
--
Maarten Boekhold, boekhold@tibco.com
TIBCO Finance Technology Inc.
The Atrium
Strawinskylaan 3051
1077 ZX Amsterdam, The Netherlands
tel: +31 20 3012158, fax: +31 20 3012358
http://www.tibco.com
Hi Maarten, > Hi, > > I don't know about the crashes, but try using 'SELECT' > instead of 'SALACT' (where the hell did you get *that* > from??). > Well. I never tried SALACT. I wanted to express that if one would do so the backend would die abnormally on the HP-Ux system. (On a Linux system I do not see this behaviour.) If you want a more real life example: The int2 regression test creates also two SQL errors. Once it tries to insert something like 'abfdgd' into an in2 field. Since the int2 test tries twice to "fool" the database the backend dies abnormally. For this reason I cannot get any result from the regression test and I do not know if I can rely on my Postgres Installation. Kind regards, Reiner Nippes UMS GmbH, Ulm - Germany
>
> Hi Maarten,
>
> > Hi,
> >
> > I don't know about the crashes, but try using 'SELECT'
> > instead of 'SALACT' (where the hell did you get *that*
> > from??).
> >
>
> Well. I never tried SALACT. I wanted to express that if one would
> do so the backend would die abnormally on the HP-Ux system.
> (On a Linux system I do not see this behaviour.)
>
> If you want a more real life example: The int2 regression test
> creates also two SQL errors. Once it tries to insert something like
> 'abfdgd' into an in2 field. Since the int2 test tries twice to "fool" the
> database the backend dies abnormally. For this reason I cannot
> get any result from the regression test and I do not know if I can
> rely on my Postgres Installation.
>
> Kind regards,
> Reiner Nippes
So any multiple occurence of parse errors crashes your
backend. Can you get coredump from the crashing backend (if
the postmaster is started from a shell where coresize limit
is unlimited you should find one in the database directory
after the crash)?
Could you then please produce a stack backtrace with gdb so
we might be able to track the problem down?
And please save the core file once you have it. We might have
further questions.
Jan
--
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#======================================== jwieck@debis.com (Jan Wieck) #
Hi,
> So any multiple occurence of parse errors crashes your
> backend. Can you get coredump from the crashing backend (if
> the postmaster is started from a shell where coresize limit
> is unlimited you should find one in the database directory
> after the crash)?
>
> Could you then please produce a stack backtrace with gdb so
> we might be able to track the problem down?
#0 0xc00a9098 in memset ()
(gdb) backtrace
#0 0xc00a9098 in memset ()
#1 0x15d0e8 in PostgresMain (argc=-534762622, argv=0x203cb000,
real_argc=-534763790, real_argv=0x203cb000) at postgres.c:1582
#2 0xe0202530 in ?? ()
Cannot access memory at address 0x203cafe8.
(gdb) frame 0
#0 0xc00a9098 in memset ()
(gdb) list
75 elog(NOTICE, "setsysinfo failed: %d\n", errno);
76 #endif
77
78 #endif /* NOFIXADE || NOPRINTADE */
79
80 /*
81 * use one executable for both postgres and postmaster, invoke o
ne or
82 * the other depending on the name of the executable
83 */
84 len = strlen(argv[0]);
(gdb) frame 1
#1 0x15d0e8 in PostgresMain (argc=-534762622, argv=0x203cb000,
real_argc=-534763790, real_argv=0x203cb000) at postgres.c:1582
1582 MemSet(parser_input, 0, MAX_PARSE_BUFFER);
(gdb) list
1577
1578 /* ----------------
1579 * (3) read a command.
1580 * ----------------
1581 */
1582 MemSet(parser_input, 0, MAX_PARSE_BUFFER);
1583
1584 firstchar = ReadCommand(parser_input);
1585
1586 QueryCancel = false; /* forget any earlier CANCEL sig
nal */
(gdb)
> And please save the core file once you have it. We might have
> further questions.
Kind regards,
Reiner Nippes
United Monolithic Semiconductors GmbH
Ulm - Germany
> #0 0xc00a9098 in memset ()
> (gdb) backtrace
> #0 0xc00a9098 in memset ()
> #1 0x15d0e8 in PostgresMain (argc=-534762622, argv=0x203cb000,
> real_argc=-534763790, real_argv=0x203cb000) at postgres.c:1582
> #2 0xe0202530 in ?? ()
> Cannot access memory at address 0x203cafe8.
>
> (gdb) frame 1
> #1 0x15d0e8 in PostgresMain (argc=-534762622, argv=0x203cb000,
> real_argc=-534763790, real_argv=0x203cb000) at postgres.c:1582
> 1582 MemSet(parser_input, 0, MAX_PARSE_BUFFER);
> (gdb) list
> 1577
> 1578 /* ----------------
> 1579 * (3) read a command.
> 1580 * ----------------
> 1581 */
> 1582 MemSet(parser_input, 0, MAX_PARSE_BUFFER);
> 1583
> 1584 firstchar = ReadCommand(parser_input);
> 1585
> 1586 QueryCancel = false; /* forget any earlier CANCEL sig
> nal */
> (gdb)
Bingo!
MemSet() is a macro in src/include/c.h which in this case
calls the real memset() library function (area to set is
greater than 64 bytes).
parser_input is a dynamic char array inside of
PostgresMain(), so it's part of the innermost stackframe.
This looks to me like the execution of longjmp() from the
elog() corrupted the stackframe of PostgresMain() instead of
restoring it as it should have done.
There are different kinds of jumps used depending on the
installation. One is setjmp()/longjmp() the other is
sigsetjmp()/siglongjmp(). If I recall correct, sigsetjmp() is
#defined to setjmp() if it isn't available.
So folks, low level HP/UX 10.10 know how required!
Jan
--
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#======================================== jwieck@debis.com (Jan Wieck) #