So as promised - the patch is very stable. No more memory problems,
neither any other issues.
Great job Yamada-san
Dave - can I assume you'll manage this fix to be pushed to official
release?
On 9 Lip, 17:08, wstrzalka wrote:
> Looks very good by now.
>
> I'll test the version f
Hi
reading google.. i come to here... maybe i can help more about this issue.
on server pglog:
2009-07-15 09:40:27 BRTLOG: could not receive data from client: Unknown
winsock error 10061
2009-07-15 09:40:27 BRTLOG: unexpected EOF on client connection
2009-07-15 09:41:35 BRTLOG: could not rece
Looks very good by now.
I'll test the version for a few days in my regular work and will
post more feedback here.
On 8 Lip, 17:37, dp...@pgadmin.org (Dave Page) wrote:
> On Wed, Jul 8, 2009 at 2:03 PM, Tsutomu Yamada wrote:
> > In the past, there was the thread about this problem,
> > and it
On Wed, Jul 8, 2009 at 2:03 PM, Tsutomu Yamada wrote:
> In the past, there was the thread about this problem,
> and it suggested using VirtualAllocEx().
> (But no patch was posted, right?)
> http://archives.postgresql.org/pgsql-general/2007-08/msg01592.php
>
> So I tries using VirtualAllocEx().
>
When the server starts, it should also spew out the initial shmem
segment ID and address - did you get them? They may go to stderr
rather than the log, because they're output so early in the startup. I
assume they're the same because one of the attaches seems to work
fine.
2009/7/8 Wojciech Strza
Dave Page wrote:
> 2009/7/7 Wojciech Strzałka :
> >
> > Here ( http://www.codelabs.pl/_varia/pg.zip ) is detailed info from
> > my machine (PostgreSQL 8.3.6, compiled by Visual C++ build 1400):
> >
> > - detailed log file with several memory attach problems
> > - process activity log fi
And the result is:
2009-07-08 14:26:00 CEST PID:9612 DEBUG: 0: forked new backend, pid=8120
socket=948
2009-07-08 14:26:00 CEST PID:9612 LOCATION: BackendStartup,
.\src\backend\postmaster\postmaster.c:3029
*** Finished restoring shared memory vars in restore_backend_variables
(key=256, ad
Witam!
W liście datowanym 8 lipca 2009 (13:55:00) napisano:
> 2009/7/8 Wojciech Strzałka :
>> I was wondering why I can not see the DEBUG2 info you were talking
>> about (tripple star), and probably that's another bug.
>> Whichever debug1 - debug5 level I set in config file the pg_settings
>>
2009/7/8 Wojciech Strzałka :
> I was wondering why I can not see the DEBUG2 info you were talking
> about (tripple star), and probably that's another bug.
> Whichever debug1 - debug5 level I set in config file the pg_settings
> tells me that it's set to 'debug' (without a number) - and there i
Witam!
W liście datowanym 7 lipca 2009 (18:02:30) napisano:
> 2009/7/7 Wojciech Strzałka :
>>
>> I think both 8.3 & 8.4 are from EnterpriseDB (the integer_datetime
>> is 'off' at least in 8.3 which is active at the time).
> OK, I put a zip of a server build at
> http://uploads.enterprisedb.com
2009/7/7 Wojciech Strzałka :
>
> I think both 8.3 & 8.4 are from EnterpriseDB (the integer_datetime
> is 'off' at least in 8.3 which is active at the time).
OK, I put a zip of a server build at
http://uploads.enterprisedb.com/download.php?file=fc168613430d6c1bf756036466963a5f
It's PG84, and inc
I think both 8.3 & 8.4 are from EnterpriseDB (the integer_datetime
is 'off' at least in 8.3 which is active at the time).
Don't hesitate too much - reinstalling binaries with dump & restore of
data is not a problem whatever version you'll send to me.
> 2009/7/7 Wojciech Strzałka :
>>
>>
2009/7/7 Wojciech Strzałka :
>
> Sorry if what i'm talking is completely silly, but
> the error code (ERROR_INVALID_ADDRESS - 487 (0x1E7)) returned from
> MapViewOfFileEx suggest the ShMem address is wrong. The Windows
> error codes are usually not really helpfull but
> can we log the Use
Sorry if what i'm talking is completely silly, but
the error code (ERROR_INVALID_ADDRESS - 487 (0x1E7)) returned from
MapViewOfFileEx suggest the ShMem address is wrong. The Windows
error codes are usually not really helpfull but
can we log the UsedShmemSegAddr and UsedShmemSegID in
2009/7/7 Wojciech Strzałka :
>
> Here ( http://www.codelabs.pl/_varia/pg.zip ) is detailed info from
> my machine (PostgreSQL 8.3.6, compiled by Visual C++ build 1400):
>
> - detailed log file with several memory attach problems
> - process activity log file (created by Process Monitor from Sys
Here ( http://www.codelabs.pl/_varia/pg.zip ) is detailed info from
my machine (PostgreSQL 8.3.6, compiled by Visual C++ build 1400):
- detailed log file with several memory attach problems
- process activity log file (created by Process Monitor from SysInternals)
- dll's loaded by post
2009/7/6 Alvaro Herrera :
> Wojciech Strzałka escribió:
>>
>> I don't suppose this explains anything but - why not to try (this is
>> DEBUG and has more details, but looks like some information are less
>> detailed than in
>> INFO log level ?? (ie. socket error code is missing):
>
> I suggest you
Wojciech Strzałka escribió:
>
> I don't suppose this explains anything but - why not to try (this is
> DEBUG and has more details, but looks like some information are less detailed
> than in
> INFO log level ?? (ie. socket error code is missing):
I suggest you add %p to log_line_prefix to differ
I don't suppose this explains anything but - why not to try (this is
DEBUG and has more details, but looks like some information are less detailed
than in
INFO log level ?? (ie. socket error code is missing):
2009-07-06 23:31:12 CEST DEBUG: 0: shmem_exit(0)
2009-07-06 23:31:12 CEST LOCATION
In my case standby mode only increases the frequency - problem occurs
also on clean machine - right after startup.
8.4 is totally unusable on my vista. I had to downgrade back to 8.3
I've just uninstalled antivirus & disabled windows firewall - no
effect.
The strange is that subsequent request
Wojciech Strza?ka wrote:
> All of the machines are laptops. Maybe some power management stuff ?
I experienced problems with the Standby mode (that was with pg8.2 and XPSP2).
But since this is a workstation I just stopped using the Standby mode.
I never looked into the log files but what happened
2009/7/6 Wojciech Strzałka :
>
> No really a pattern.
> I'm sure PG is installed in standard pure version everywhere.
> No domains at all.
> The rest is really custom (we are working remotely - each of us with
> different hardware, OS, software, etc...).
> Maybe the intel dual core has smth t
All of the machines are laptops. Maybe some power management stuff ?
> On Mon, Jul 6, 2009 at 11:20 AM, wstrzalka wrote:
>> After upgrading to 8.4 on Vista I see no progress on the shared memory
>> problem unfortunately.
>>
>> I think it's even worse now (previously it happened mainly when OS
No really a pattern.
I'm sure PG is installed in standard pure version everywhere.
No domains at all.
The rest is really custom (we are working remotely - each of us with
different hardware, OS, software, etc...).
Maybe the intel dual core has smth to do about it ?
Those are affected:
My
On Mon, Jul 6, 2009 at 11:20 AM, wstrzalka wrote:
> After upgrading to 8.4 on Vista I see no progress on the shared memory
> problem unfortunately.
>
> I think it's even worse now (previously it happened mainly when OS
> went to sleep & then was restored, now it's all the time).
>
> My log looks li
After upgrading to 8.4 on Vista I see no progress on the shared memory
problem unfortunately.
I think it's even worse now (previously it happened mainly when OS
went to sleep & then was restored, now it's all the time).
My log looks like this.
-
26 matches
Mail list logo
