Added to TODO:
* Remove use of MAKE_PTR and MAKE_OFFSET macros
http://archives.postgresql.org/pgsql-general/2007-08/msg01510.php
---
Tom Lane wrote:
Gregory Stark [EMAIL PROTECTED] writes:
Trevor Talbot [EMAIL
not reattach to
shared memory (Win32)
8.3 will have a new way to deal with shared mem on win32. It's the
same underlying tech, but we're no longer trying to squeeze it into
an emulation of sysv. With a bit of luck, that'll help :-)
//Magnus
Wild guess on my part... could
] To: Alvaro Herrera
[EMAIL PROTECTED] Cc: Terry Yapt [EMAIL PROTECTED];
pgsql-general@postgresql.org Sent: Thursday, August 23, 2007
3:43:32 PM Subject: Re: [GENERAL] FATAL: could not reattach to
shared memory (Win32)
8.3 will have a new way to deal with shared mem on win32. It's
On 8/24/07, Tom Lane [EMAIL PROTECTED] wrote:
Trevor Talbot [EMAIL PROTECTED] writes:
On 8/23/07, Magnus Hagander [EMAIL PROTECTED] wrote:
Not that wild a guess, really :-) I'd say it's a very good possibility -
but I have no idea why it'd do that, since all backends load the same
DLLs at
Trevor Talbot escribió:
The environment is consistent then. Whatever is going on, when
postgres first starts things are normal, something just changes later
and the change is temporary. As vague guides, I would look at some
kind of global resource usage/tracking, and scheduled tasks. Do you
Shelby Cain wrote:
- Original Message From: Magnus Hagander
[EMAIL PROTECTED] To: Alvaro Herrera
[EMAIL PROTECTED] Cc: Terry Yapt [EMAIL PROTECTED];
pgsql-general@postgresql.org Sent: Thursday, August 23, 2007
3:43:32 PM Subject: Re: [GENERAL] FATAL: could not reattach to
shared
On 8/23/07, Magnus Hagander [EMAIL PROTECTED] wrote:
Shelby Cain wrote:
Wild guess on my part... could that error be the result of an attempt
to map shared memory into a process at a fixed location that just
happens to already be occupied by a dll that Windows had decided to
relocate?
Trevor Talbot [EMAIL PROTECTED] writes:
I gather postgres depends on it being at the same address, and fixing that
isn't trivial?
I haven't been following the rest of the thread so I'm not sure if this is
important. But no, fixing that should be relatively trivial as there are
already some
Trevor Talbot wrote:
On 8/23/07, Magnus Hagander [EMAIL PROTECTED] wrote:
Shelby Cain wrote:
Wild guess on my part... could that error be the result of an attempt
to map shared memory into a process at a fixed location that just
happens to already be occupied by a dll that Windows
Gregory Stark wrote:
Trevor Talbot [EMAIL PROTECTED] writes:
I gather postgres depends on it being at the same address, and fixing that
isn't trivial?
I haven't been following the rest of the thread so I'm not sure if this is
important. But no, fixing that should be relatively trivial
Trevor Talbot [EMAIL PROTECTED] writes:
On 8/23/07, Magnus Hagander [EMAIL PROTECTED] wrote:
Not that wild a guess, really :-) I'd say it's a very good possibility -
but I have no idea why it'd do that, since all backends load the same
DLLs at that stage.
Not a valid assumption; you can't
Gregory Stark [EMAIL PROTECTED] writes:
Trevor Talbot [EMAIL PROTECTED] writes:
I gather postgres depends on it being at the same address, and fixing that
isn't trivial?
I haven't been following the rest of the thread so I'm not sure if this is
important. But no, fixing that should be
Tom Lane escribió:
There are a few old bits of code that still use MAKE_PTR/MAKE_OFFSET,
but I think it's mostly just that no one's bothered to rewrite the code
for SHM_QUEUE linked lists. The vast majority of our shmem structures
use regular pointers, and have for years.
... except that,
Tom Lane [EMAIL PROTECTED] writes:
There are a few old bits of code that still use MAKE_PTR/MAKE_OFFSET,
but I think it's mostly just that no one's bothered to rewrite the code
for SHM_QUEUE linked lists. The vast majority of our shmem structures
use regular pointers, and have for years.
- Original Message
From: Magnus Hagander [EMAIL PROTECTED]
To: Shelby Cain [EMAIL PROTECTED]
Cc: Alvaro Herrera [EMAIL PROTECTED]; Terry Yapt [EMAIL PROTECTED];
pgsql-general@postgresql.org
Sent: Friday, August 24, 2007 1:08:44 AM
Subject: Re: [GENERAL] FATAL: could not reattach
-general@postgresql.org
Sent: Friday, August 24, 2007 1:08:44 AM
Subject: Re: [GENERAL] FATAL: could not reattach to shared memory (Win32)
Not that wild a guess, really :-) I'd say it's a very good possibility -
but I have no idea why it'd do that, since all backends load the same
DLLs at that stage
Gregory Stark [EMAIL PROTECTED] writes:
Tom Lane [EMAIL PROTECTED] writes:
There are a few old bits of code that still use MAKE_PTR/MAKE_OFFSET,
but I think it's mostly just that no one's bothered to rewrite the code
for SHM_QUEUE linked lists. The vast majority of our shmem structures
use
Tom Lane escribió:
I'm not sure if you have a specific technical meaning of clone in mind
here, but these processes are all executing the identical executable,
and taking care to map the shmem early in execution *before* they load
any DLLs. So it should work. Apparently, it *does* work for
Shelby Cain [EMAIL PROTECTED] writes:
Assuming this is an issue with shared libraries, I think it would have more=
to do with the way Windows resolves address conflicts on process startup t=
han anything caused by explicit calls to LoadLibrary(). Looking at postgre=
s.exe with the dependency
Tom Lane [EMAIL PROTECTED] writes:
Gregory Stark [EMAIL PROTECTED] writes:
Tom Lane [EMAIL PROTECTED] writes:
There are a few old bits of code that still use MAKE_PTR/MAKE_OFFSET,
but I think it's mostly just that no one's bothered to rewrite the code
for SHM_QUEUE linked lists. The vast
Hello all,
I am having problems with the next postgresql version:
pg version: 8.2.4
OS: Win32 (windows xp sp2)
FS: NTFS
It is a production server, but suddenly the DB stop answering to any sql
command. It seems dead. After restart server all starts to works again.
I am looking for system
Terry Yapt wrote:
I am looking for system errors and nothing is there. But I have a lot of
messages on system APP errors. The error is the same every ten seconds or
so.
This is the main error:
* FATAL: could not reattach to shared memory (key=5432001, addr=01D8):
Invalid argument
Sorry, I have not be able to execute ipcs on windows. it doesn't
exists. I have tried to find some utility that gives me the same
information or any ipcs porting to win32, but I haven't had any luck.
If I can do something more to get help, please tell me.
Greetings.
Alvaro Herrera
Terry Yapt wrote:
This is the main error:
* FATAL: could not reattach to shared memory (key=5432001, addr=01D8):
Invalid argument
It is always followed by this another system-app error:
* LOG: unrecognized win32 error code: 487
FWIW,
Alvaro Herrera escribió:
Terry Yapt wrote:
This is the main error:
* FATAL: could not reattach to shared memory (key=5432001, addr=01D8):
Invalid argument
It is always followed by this another system-app error:
* LOG: unrecognized win32 error code: 487
This problem has been
Alvaro Herrera wrote:
Terry Yapt wrote:
This is the main error:
* FATAL: could not reattach to shared memory (key=5432001, addr=01D8):
Invalid argument
It is always followed by this another system-app error:
* LOG: unrecognized win32 error code: 487
FWIW,
Magnus Hagander wrote:
Alvaro Herrera wrote:
No resolution seems to have been found.
8.3 will have a new way to deal with shared mem on win32. It's the same
underlying tech, but we're no longer trying to squeeze it into an
emulation of sysv. With a bit of luck, that'll help :-)
So you're
- Original Message
From: Magnus Hagander [EMAIL PROTECTED]
To: Alvaro Herrera [EMAIL PROTECTED]
Cc: Terry Yapt [EMAIL PROTECTED]; pgsql-general@postgresql.org
Sent: Thursday, August 23, 2007 3:43:32 PM
Subject: Re: [GENERAL] FATAL: could not reattach to shared memory (Win32)
8.3
Alvaro Herrera [EMAIL PROTECTED] writes:
Magnus Hagander wrote:
8.3 will have a new way to deal with shared mem on win32. It's the same
underlying tech, but we're no longer trying to squeeze it into an
emulation of sysv. With a bit of luck, that'll help :-)
So you're saying we won't fix this
29 matches
Mail list logo
