Re: PostgreSQL 8.1.2 crashes diring import...

2006-01-24 Thread Reini Urban
I see in your previous mail, that your cygserver SHM settings
are already at the maximum. Hope that your have that much RAM/Virtual Memory.

The previous error was an interrupted call error 2, which is not the case
with your problem.
Jason's Problem:
3 [main] postmaster 1144 transport_layer_pipes::connect: lost connection
to cygserver, error = 2
...
FATAL:  could not create shared memory segment: Interrupted system call
DETAIL:  Failed system call was shmget(key=5432001, size=8970240, 03600).

Your problem:
9 [main] postmaster 656 transport_layer_pipes::connect: lost
connection to cygserver, error = 121

Can you try running cygserver with -d. For testing best started from the
console, not as service. Maybe within a sysbash to have the same
permissions.

BTW: My cygwin packages 8.06 and 8.1.2 to test against are at
the setup User Url: http://xarch.tu-graz.ac.at/publ/cygwin/

I haven't tested yet such a big 3-4GIG import, a huge index might need
more than with 8.0, but the heavy and parallel regressions do all pass
so far.

 Adding to my own message.

 Just found this, which is from two years ago and reflects on the same
 problem -

 http://www.cygwin.com/ml/cygwin-apps/2004-01/msg00014.html

 This e-mail says that cygserver simply exits upon high load upon
 PostgreSQL.

 This e-mail says that the problem is fixed -

 http://www.cygwin.com/ml/cygwin-apps/2004-01/msg00179.html

 Could it be that the problem has come back?

Could be but I doubt it.
-- 
Reini Urban
http://phpwiki.org/   http://xarch.tu-graz.ac.at/home/rurban/



--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/



Re: PostgreSQL 8.1.2 crashes diring import...

2006-01-24 Thread [EMAIL PROTECTED]

Reini Urban wrote:

I see in your previous mail, that your cygserver SHM settings
are already at the maximum. Hope that your have that much RAM/Virtual Memory.


I did this just desperately looking for solution, but seems the problem 
is not there.



Your problem:
9 [main] postmaster 656 transport_layer_pipes::connect: lost
connection to cygserver, error = 121

Can you try running cygserver with -d. For testing best started from the
console, not as service. Maybe within a sysbash to have the same
permissions.


Yes, I did that but did not include it in the e-mail, as I did not see 
anything meaningful there (no obvious error message). I'll do it again 
and send it to the list in the next 2-3 days (lost time the last 1-2 
days with this).



BTW: My cygwin packages 8.06 and 8.1.2 to test against are at
the setup User Url: http://xarch.tu-graz.ac.at/publ/cygwin/


I went back to 8.0.4. I need something which I understand how it happens 
and why. Thanks, however.



I haven't tested yet such a big 3-4GIG import, a huge index might need
more than with 8.0, but the heavy and parallel regressions do all pass
so far.


OK I'll do the -d option and then we will see if we can do something.

Thanks for your input,
Iv


--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/



PostgreSQL 8.1.2 crashes diring import - 8.0.4 does not

2006-01-23 Thread [EMAIL PROTECTED]
I am not sure if this is relevant for here, but as cygserver is 
involved, I thought it might be interesting.


PostgreSQL 8.1.2 crashes during import (postmaster loses connection to 
cygserver, details below) and 8.0.4 does the same import without problem 
(all versions since 7.4, if I am not wrong, worked fine with the same 
database).


Both 8.1.2 and 8.0.4 are compiled from source (./configure make make
install).

PostgreSQL 8.1.2 crashes again and again on the same place (somewhere
around the end of the import, after heavy indexes). Clean cygwin install
did not help. Increased configuration options (quoted below) of
cygserver did not help. Database is 3-4 GB imported, with indexes.

Does anyone have an idea what can it be?

Thanks,
Iv

--

psql last messages:

psql:db.sql:10372960: server closed the connection unexpectedly
This probably means the server terminated abnormally
before or while processing the request.
psql:db.sql:10372960: connection to server was lost

--

postmaster last messages:

  9 [main] postmaster 656 transport_layer_pipes::connect: lost
connection to cygserver, error = 121
LOG:  server process (PID 656) was terminated by signal 12
LOG:  terminating any other active server processes
LOG:  all server processes terminated; reinitializing
LOG:  database system was interrupted at 2006-01-24 00:18:13
LOG:  checkpoint record is at 1/5D901490
LOG:  redo record is at 1/5D901490; undo record is at 0/0; shutdown FALSE
LOG:  next transaction ID: 2340; next OID: 31154176
LOG:  next MultiXactId: 1; next MultiXactOffset: 0
LOG:  database system was not properly shut down; automatic recovery in
progress
LOG:  redo starts at 1/5D9014D8
LOG:  record with zero length at 1/5D916268
LOG:  redo done at 1/5D916218
LOG:  database system is ready
LOG:  transaction ID wrap limit is 2147484146, limited by database
postgres

--

cygserver.conf

# cygserver.conf, Copyright(C) 2003, 2005 Red Hat Inc.
#
# Contains configurable parameters for the cygserver.
#
# The format of this file is easy.  Lines beginning with a hash `#' are
# comments and ignored.  Lines consisting of only whitespaces are ignored.
# Any other line is a setting for cygserver.
# A setting consists of a name/value pair, separated by whitespace.
# Each line must only consist of one name/value pair.
# Lines must not be longer than 1023 characters.
#
# Some settings can be overridden by a command line switch.  If so, it's
# mentioned below.
#
# Settings which are commented out will use the default values.  These are
# mentioned below, too.

# kern.srv.cleanup_threads: No. of cygserver threads used for cleanup tasks.
# Default: 2, Min: 1, Max: 16, command line option -c, --cleanup-threads
#kern.srv.cleanup_threads 2

# kern.srv.request_threads: No. of cygserver threads used to serve
#   application requests.
# Default: 10, Min: 1, Max: 310, command line option -r, --request-threads
#kern.srv.request_threads 10

# kern.srv.process_cache_size: No. of concurrent processes which can be
handled
#  by Cygserver concurrently.
# Default: 62, Min: 1, Max: 310, command line option -p, --process-cache
#kern.srv.process_cache_size 62

# kern.srv.msgqueues: Determines whether XSI Message Queue support should be
# started, yes (or true, y, t, 1) or no (or false, n,
f, 0).
# These values are valid for all binary type options.
# Default is yes.  Command line option -q, --no-msgqueues
#kern.srv.msgqueues yes

# kern.srv.semaphores: Determines whether XSI Semaphore support should be
# started.  Default is yes.  Command line option -s, --no-semaphores
#kern.srv.semaphores yes

# kern.srv.sharedmem: Determines whether XSI Shared Memory support should be
# started.  Default is yes.  Command line option -m, --no-sharedmem
#kern.srv.sharedmem yes

# LOGGING

# kern.log.syslog: Determines whether logging should go to the syslog,
# Default is yes, if stderr is no tty, no otherwise.
# Command line option -y, --syslog or -Y, --no-syslog.
#kern.log.syslog no

# kern.log.stderr: Determines whether logging should go to stderr,
# Default is yes, if stderr is a tty, no otherwise.
# Command line option -e, --stderr or -E, --no-stderr.
#kern.log.stderr no

# kern.log.level: Logging level.  Valid values are 1 to 7 with a bigger
# value emitting more logging output.  Default level is 6.
# Command line option -l, --log-level.
#kern.log.level 6

# kern.log.debug: Determines whether debug output should be printed to
stderr.
# Default is no.  Command line option -d, --debug
#kern.log.debug no

# XSI message queue parameters.
#
# Each message is broken up and stored in segments that are msgssz bytes
# long.  For efficiency reasons, this should be a power of two.  Also,
# it doesn't make sense if it is less than 8 or greater than about 256.

# kern.ipc.msgseg: Maximum no. of message queue segments hold concurrently.
# Default: 2048, Min: 256, Max: 65535
#kern.ipc.msgseg 2048

# kern.ipc.msgssz: Size of segment in 

Re: PostgreSQL 8.1.2 crashes diring import...

2006-01-23 Thread [EMAIL PROTECTED]

Adding to my own message.

Just found this, which is from two years ago and reflects on the same 
problem -


http://www.cygwin.com/ml/cygwin-apps/2004-01/msg00014.html

This e-mail says that cygserver simply exits upon high load upon PostgreSQL.

This e-mail says that the problem is fixed -

http://www.cygwin.com/ml/cygwin-apps/2004-01/msg00179.html

Could it be that the problem has come back?

Iv


--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/