Thread: Cygwin-Postgres-IpcMemoryCreate
This was initially posted in comp.databases.postgresql.ports.cygwin. Updates: If using the rename() instead of link() the following error is not experienced anymore. > 1) FATAL 2: link from /cygdrive/C/pg/data/pg_xlog/0000000000000004 to > /cygdrive/C/pg/data/pg_xlog/0000000000000007 (initialization of log > file 0, segment 7) failed: Permission denied But the following error,I think, is independent of the above one. > DEBUG: all server processes terminated; reinitializing shared memory > and semaphores > IpcMemoryCreate: shmget(key=5432001, size=1441792, 03600) failed: Not > enough memory Please the read the following initial post anyway. Thanks, > > Sorry about including a large section of the log file in the end. > > > > I'm Running Postgres 7.2.1 on W2K box, Cygwin DLL 1.3.10 with 384M > > Memory. > > > > I'm pretty sure I have around 200M free memory when this error occurs. > > > > If I look at the sequence of actions in the log, > > > > 1) FATAL 2: link from /cygdrive/C/pg/data/pg_xlog/0000000000000004 to > > /cygdrive/C/pg/data/pg_xlog/0000000000000007 (initialization of log > > file 0, segment 7) failed: Permission denied > > 2) One child process exits > > 3) SIGQUIT is sent to the other processes. > > 4) All the other children die > > 5) Reinitialize processes (all server processes terminated; > > reinitializing shared memory and semaphores) > > 6) Then the error reads, IpcMemoryCreate: shmget(key=5432001, > > size=1441792, 03600) failed: Not enough memory > > > > > > Please help. > > > > > > The actual log file section is below. > > > > > > > > FATAL 2: link from /cygdrive/C/pg/data/pg_xlog/0000000000000004 to > > /cygdrive/C/pg/data/pg_xlog/0000000000000007 (initialization of log > > file 0, segment 7) failed: Permission denied > > ... > > ... > > ... > > ... > > .... > > ... > > DEBUG: reaping dead processes > > DEBUG: child process (pid 488) exited with exit code 2 > > DEBUG: server process (pid 488) exited with exit code 2 > > DEBUG: terminating any other active server processes > > DEBUG: CleanupProc: sending SIGQUIT to process 320 > > DEBUG: CleanupProc: sending SIGQUIT to process 2920 > > DEBUG: CleanupProc: sending SIGQUIT to process 1996 > > DEBUG: CleanupProc: sending SIGQUIT to process 2940 > > NOTICE: Message from PostgreSQL backend: > > The Postmaster has informed me that some other backend > > died abnormally and possibly corrupted shared memory. > > I have rolled back the current transaction and am > > going to terminate your database system connection and exit. > > Please reconnect to the database system and repeat your query. > > DEBUG: StartTransactionCommand > > DEBUG: CommitTransactionCommand > > DEBUG: StartTransactionCommand > > DEBUG: CommitTransactionCommand > > DEBUG: StartTransactionCommand > > DEBUG: CommitTransactionCommand > > DEBUG: StartTransactionCommand > > DEBUG: CommitTransactionCommand > > NOTICE: Message from PostgreSQL backend: > > The Postmaster has informed me that some other backend > > died abnormally and possibly corrupted shared memory. > > I have rolled back the current transaction and am > > going to terminate your database system connection and exit. > > Please reconnect to the database system and repeat your query. > > NOTICE: Message from PostgreSQL backend: > > The Postmaster has informed me that some other backend > > died abnormally and possibly corrupted shared memory. > > I have rolled back the current transaction and am > > going to terminate your database system connection and exit. > > Please reconnect to the database system and repeat your query. > > NOTICE: Message from PostgreSQL backend: > > The Postmaster has informed me that some other backend > > died abnormally and possibly corrupted shared memory. > > I have rolled back the current transaction and am > > going to terminate your database system connection and exit. > > Please reconnect to the database system and repeat your query. > > DEBUG: reaping dead processes > > DEBUG: child process (pid 320) exited with exit code 1 > > DEBUG: reaping dead processes > > DEBUG: child process (pid 2920) exited with exit code 1 > > DEBUG: child process (pid 1996) exited with exit code 1 > > DEBUG: reaping dead processes > > DEBUG: reaping dead processes > > DEBUG: child process (pid 2940) exited with exit code 1 > > DEBUG: all server processes terminated; reinitializing shared memory > > and semaphores > > IpcMemoryCreate: shmget(key=5432001, size=1441792, 03600) failed: Not > > enough memory > > > > This error usually means that PostgreSQL's request for a shared > > memory segment exceeded available memory or swap space. > > To reduce the request size (currently 1441792 bytes), reduce > > PostgreSQL's shared_buffers parameter (currently 64) and/or > > its max_connections parameter (currently 32). > > > > The PostgreSQL Administrator's Guide contains more information about > > shared memory configuration.
On Tue, Apr 16, 2002 at 02:34:08PM -0700, Saravanan Bellan wrote:
> This was initially posted in comp.databases.postgresql.ports.cygwin.
>
> Updates:
>
> If using the rename() instead of link() the following error is not
> experienced anymore.
>
> > 1) FATAL 2: link from /cygdrive/C/pg/data/pg_xlog/0000000000000004 to
> > /cygdrive/C/pg/data/pg_xlog/0000000000000007 (initialization of log
> > file 0, segment 7) failed: Permission denied
Please post your patch for the above, so we know precisely what change
you needed to make to solve your problem. If the patch looks good,
then the next step would be to post it to pgsql-patches for consideration.
Note, however, that I have never seen an error message like the above.
What is your system info?
Cygwin version
cygipc version
Windows version
CYGWIN environment variable setting
filesystem type (i.e., NTFS, FAT, etc.)
> But the following error,I think, is independent of the above one.
>
> > DEBUG: all server processes terminated; reinitializing shared memory
> > and semaphores
> > IpcMemoryCreate: shmget(key=5432001, size=1441792, 03600) failed: Not
> > enough memory
I have seen the above error message when the permissions of the following
files were incorrect:
/tmp/cygipc*
/tmp/MultiFile*
Try removing them to see if this is your problem.
> Please the read the following initial post anyway.
>
> [snip]
BTW, I just built and tested PostgreSQL 7.2.1 under Cygwin 1.3.10. make
installcheck passed all tests.
Jason
> From: Jason Tishler [mailto:jason@tishler.net] > > > On Tue, Apr 16, 2002 at 02:34:08PM -0700, Saravanan Bellan wrote: > > This was initially posted in comp.databases.postgresql.ports.cygwin. > > > > Updates: > > > > If using the rename() instead of link() the following error is not > > experienced anymore. > > > > > 1) FATAL 2: link from > /cygdrive/C/pg/data/pg_xlog/0000000000000004 to > > > /cygdrive/C/pg/data/pg_xlog/0000000000000007 > (initialization of log > > > file 0, segment 7) failed: Permission denied > > Please post your patch for the above, so we know precisely what change > you needed to make to solve your problem. If the patch looks good, > then the next step would be to post it to pgsql-patches for > consideration. > > Note, however, that I have never seen an error message like the above. > What is your system info? > I just saw the above error when trying to upgrade to 7.2.1 from 7.1.3 (as well changing servers) and putting the data in. Here's my error log: DEBUG: recycled transaction log file 0000000000000097 FATAL 1: No pg_hba.conf entry for host 10.20.1.76, user sdb, database dp_test FATAL 1: No pg_hba.conf entry for host 10.20.1.76, user sdb, database dp_test FATAL 2: link from /usr/local/pgsql/data/pg_xlog/0000000000000097 to /usr/local /pgsql/data/pg_xlog/00000000000000A0 (initialization of log file 0, segment 160) failed: Permission denied DEBUG: server process (pid 381) exited with exit code 2 DEBUG: terminating any other active server processes DEBUG: all server processes terminated; reinitializing shared memory and semaph ores IpcMemoryCreate: shmget(key=5432001, size=174891008, 03600) failed: Not enough m emory This error usually means that PostgreSQL's request for a shared memory segment exceeded available memory or swap space. uname -a: CYGWIN_NT-4.0 DPRINT 1.3.10(0.51/3/2) 2002-02-25 11:14 I686 unknown This is with a self built postgresql-7.2.1 with --enable-debug --enable-depend make check passed all tests. The computer is a Proliant 370 with dual pIII's and 1GB of memory on an NTFS partition. postgres user is currently a member of Administrators, so should have any necessary permissions. I'm wondering if the previous memeory was not freed, therefore putting me above the default memory limit (256MB IIRC). As a side note I've been having trouble getting heap_chunk_in_mb setting in the registry to work. Has any one else managed this with ipc-daemon and postgresql run as services? - Stuart
Stuart, On Thu, Apr 18, 2002 at 11:14:38AM +0100, Henshall, Stuart - WCP wrote: > > From: Jason Tishler [mailto:jason@tishler.net] > > Note, however, that I have never seen an error message like the above. > > What is your system info? > > > I just saw the above error when trying to upgrade to 7.2.1 from 7.1.3 (as > well changing servers) and putting the data in. > Here's my error log: > [snip] > The computer is a Proliant 370 with dual pIII's and 1GB of memory on an NTFS > partition. > postgres user is currently a member of Administrators, so should have any > necessary permissions. The permission problem is probably due to the file being open by another process and the difference between how Windows and Unix deal with open files. Can you strace or (better yet) debug the problem in gdb? Thanks, Jason
> From: Jason Tishler [mailto:jason@tishler.net] > > Stuart, > > On Thu, Apr 18, 2002 at 11:14:38AM +0100, Henshall, Stuart - > WCP wrote: > > > From: Jason Tishler [mailto:jason@tishler.net] > > > Note, however, that I have never seen an error message > like the above. > > > What is your system info? > > > > > I just saw the above error when trying to upgrade to 7.2.1 > from 7.1.3 (as > > well changing servers) and putting the data in. > > Here's my error log: > > [snip] > > The computer is a Proliant 370 with dual pIII's and 1GB of > memory on an NTFS > > partition. > > postgres user is currently a member of Administrators, so > should have any > > necessary permissions. > > The permission problem is probably due to the file being open by > another process and the difference between how Windows and Unix deal > with open files. > > Can you strace or (better yet) debug the problem in gdb? > > Thanks, > Jason > Unfourtunatly not. I changed the size of shared memory requested to be on the safe side then restarted. I've not seen the error before or since. - Stuart
Sorry to get back so late on this one.
I'm using
Cygwin dll - 1.3.10
Cygipc 1.11-1
Postgres 7.2.1
Windows 2000 Professional (SP 1, Build 2195)
NTFS
I'm running a non standard postgres-cygwin installation. Using only parital
Cygwin installation and do not have a separate Windows User for postgres.
I'm starting initdb with the -U option(I think this was introduced in 7.2)
and use that user name for further connections.
The change I had to make was in src/backend/access/transam/xlog.c
In InstallXLogFileSegment, just commented link() and use the rename()
section, after reading the commnets that "rename() is an acceptable
substiute except for the truly paranoid" . I'm sure it is not a valid fix,
but seem to work for me in my setup.
On a side note, I used to see multiple 'postgres' processes in 'Windows Task
Manager' , but now because of this change or some other setup change I see
multiple 'postmaster' processes. Is there a explanation?
Thanks,
-----Original Message-----
From: Jason Tishler [mailto:jason@tishler.net]
Sent: Wednesday, April 17, 2002 1:48 PM
To: Saravanan Bellan
Cc: 'pgsql-cygwin@postgresql.org'
Subject: Re: [CYGWIN] Cygwin-Postgres-IpcMemoryCreate
On Tue, Apr 16, 2002 at 02:34:08PM -0700, Saravanan Bellan wrote:
> This was initially posted in comp.databases.postgresql.ports.cygwin.
>
> Updates:
>
> If using the rename() instead of link() the following error is not
> experienced anymore.
>
> > 1) FATAL 2: link from /cygdrive/C/pg/data/pg_xlog/0000000000000004 to
> > /cygdrive/C/pg/data/pg_xlog/0000000000000007 (initialization of log
> > file 0, segment 7) failed: Permission denied
Please post your patch for the above, so we know precisely what change
you needed to make to solve your problem. If the patch looks good,
then the next step would be to post it to pgsql-patches for consideration.
Note, however, that I have never seen an error message like the above.
What is your system info?
Cygwin version
cygipc version
Windows version
CYGWIN environment variable setting
filesystem type (i.e., NTFS, FAT, etc.)
> But the following error,I think, is independent of the above one.
>
> > DEBUG: all server processes terminated; reinitializing shared memory
> > and semaphores
> > IpcMemoryCreate: shmget(key=5432001, size=1441792, 03600) failed: Not
> > enough memory
I have seen the above error message when the permissions of the following
files were incorrect:
/tmp/cygipc*
/tmp/MultiFile*
Try removing them to see if this is your problem.
> Please the read the following initial post anyway.
>
> [snip]
BTW, I just built and tested PostgreSQL 7.2.1 under Cygwin 1.3.10. make
installcheck passed all tests.
Jason
On Mon, Apr 22, 2002 at 05:33:14PM -0700, Saravanan Bellan wrote:
> Sorry to get back so late on this one.
No problem.
> I'm using
> Cygwin dll - 1.3.10
> Cygipc 1.11-1
> Postgres 7.2.1
> Windows 2000 Professional (SP 1, Build 2195)
> NTFS
The above is my setup too.
> I'm running a non standard postgres-cygwin installation. Using only parital
> Cygwin installation and do not have a separate Windows User for postgres.
Why?
> I'm starting initdb with the -U option(I think this was introduced in 7.2)
> and use that user name for further connections.
Are the user running postmaster and the owner of the data files the
same? Can you reproduce this problem with either the basic or NT
service setup as described in the README?
> The change I had to make was in src/backend/access/transam/xlog.c
>
> In InstallXLogFileSegment, just commented link() and use the rename()
> section, after reading the commnets that "rename() is an acceptable
> substiute except for the truly paranoid" . I'm sure it is not a valid fix,
> but seem to work for me in my setup.
I was looking for a patch. Instead of the above, what about the attached
*untested* patch?
Someone should figure out why Cygwin link() fails in this situation,
but rename() succeeds. If so and it makes sense, then I will post a
patch to pgsql-patches.
> On a side note, I used to see multiple 'postgres' processes in 'Windows Task
> Manager' , but now because of this change or some other setup change I see
> multiple 'postmaster' processes. Is there a explanation?
Did you replace the postmaster symlink to postgres.exe with a copy of
postgres.exe? For example:
$ rm /usr/bin/postmaster
$ cp /usr/bin/postgres.exe /usr/bin/postmaster.exe
If so, then this explains the above.
Jason
Attachment
I've been fighting with moving a PostgreSQL database from 7.1.3 to 7.2.1, on a
Win2k SP2 box with NTFS cygwin 1.3.10, cygipc , and found that the backend
would stop on me everytime pg_restore tried to restore a very large
largeobject (like 100+ Megabytes). The error displayed would be:
-------
FATAL 2: link from /d/postgresql_data/pg_xlog/0000000000000047 to /d/postgresql
_data/pg_xlog/000000000000004F (initialization of log file 0, segment 79)
failed: Permission denied
-------
After poking around in the source, I came up with the basically the same patch
I now see you guys were discussing just recently on the pgsql-cygwin archives,
where src/backend/access/transam/xlog.c is altered to use rename() instead of
link()/unlink() - as BeOS does.
So if people need another way to reproduce the problem, one way at least for
me is to create a new database, import a single extremely large (100+mb)
object, pg_dump it with something like: pg_dump -b -Ft -f foo.pgdump.tar
mydbname, and then try to restore it with something like: pg_restore -Ft -d
mydbname foo.pgdump.tar
It'll only take one or two tries for the backend to bail out.
So maybe there is something funky going on with link/unlink, and rename would
be a better choice on cygwin.
Barry
Barry, On Mon, Apr 29, 2002 at 12:02:04PM -0500, Barry Pederson wrote: > So if people need another way to reproduce the problem, one way at least > for me is to create a new database, import a single extremely large > (100+mb) object, pg_dump it with something like: pg_dump -b -Ft -f > foo.pgdump.tar mydbname, and then try to restore it with something like: > pg_restore -Ft -d mydbname foo.pgdump.tar Thanks for the test case. > It'll only take one or two tries for the backend to bail out. So, it doesn't happen every time? Sounds like a timing issue that triggers the infamous MS Windows "feature" that prevents two processes from opening the same file. > So maybe there is something funky going on with link/unlink, and rename > would be a better choice on cygwin. Would someone be willing to take the lead of this one and strace or debug (i.e., via gdb) this problem? If so, I would be willing to take the results to pgsql-patches or cygwin-developers as appropriate. Thanks, Jason