ay, 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 the
> >> same underlying tech, but we'r
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" <[EMAI
Bruce Momjian escribió:
This has been saved for the 8.4 release:
http://momjian.postgresql.org/cgi-bin/pgpatches_hold
Update:
I have installed PostgreSQL 8.2.5 and move database from old to new
server. This was 2 weeks ago.
New Server is a Windows 2003 Server running other service
> >> <[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
> >
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
se
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 th
"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 linke
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 depen
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 aw
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 struc
]>; Terry Yapt <[EMAIL PROTECTED]>;
>pgsql-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 -
>
>- 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 A
"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 yea
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
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 shou
"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;
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 relative
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 t
"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 som
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
> > re
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:
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
>- 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
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
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,
> http:/
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 r
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,
http://help.netop.com/support/errorcodes/win
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 escrib
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 ar
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 e
30 matches
Mail list logo
