Re: [BUGS] [GENERAL] One-click installer, Windows 7 32-bit, and icacls.exe
On Fri, Sep 30, 2011 at 15:34, Karl Wright daddy...@gmail.com wrote: I saw a thread where somebody saw icacls.exe being called by the one-click installer. I'm having the same thing - the installer has been running for 45 minutes now and is basically going to have to be stopped because I'm out of time waiting for it. Looking at process monitor, it is clear that icacls.exe is going through every file on the entire system and changing its permissions. The process tree indicates that it is a child of the installer, and that it is running the command: icacls C:\ /grant kawright:RX Clearly this won't do at all and should be considered a severe installer bug. If it does, it certainly sounds like a very bad bug. However, according to the documentation for icacls (http://technet.microsoft.com/en-us/library/cc753525(WS.10).aspx), you should use /t to get it to traverse into subdirectories, and clearly it's not doing that. So I wonder why it would go across the whole filesystem - might tbere be a bug in icacls? Or maybe it has something to do with inheritance? The way inheritance-permissions works on ntfs is, um, let's call it interesting. Maybe it needs to specify the (NP) flag to not propagate inheritance or something? -- Magnus Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.com/ -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] [GENERAL] One-click installer, Windows 7 32-bit, and icacls.exe
On Mon, Oct 3, 2011 at 8:59 AM, Magnus Hagander mag...@hagander.net wrote: On Fri, Sep 30, 2011 at 15:34, Karl Wright daddy...@gmail.com wrote: I saw a thread where somebody saw icacls.exe being called by the one-click installer. I'm having the same thing - the installer has been running for 45 minutes now and is basically going to have to be stopped because I'm out of time waiting for it. Looking at process monitor, it is clear that icacls.exe is going through every file on the entire system and changing its permissions. The process tree indicates that it is a child of the installer, and that it is running the command: icacls C:\ /grant kawright:RX Clearly this won't do at all and should be considered a severe installer bug. If it does, it certainly sounds like a very bad bug. However, according to the documentation for icacls (http://technet.microsoft.com/en-us/library/cc753525(WS.10).aspx), you should use /t to get it to traverse into subdirectories, and clearly it's not doing that. So I wonder why it would go across the whole filesystem - might tbere be a bug in icacls? Yes - that's how it's supposed to work (ie. *not* using /t). The purpose of that code is to ensure that the entire path leading up to the data/installation directories is readable by the users that need it. We've had a number of reported installation failures in the past caused by weirdness where read or execute permissions weren't available for (for example) the service account user, which caused somewhat mysterious failures. Or maybe it has something to do with inheritance? The way inheritance-permissions works on ntfs is, um, let's call it interesting. Maybe it needs to specify the (NP) flag to not propagate inheritance or something? Sachin/Ashesh; can one of you investigate this please? Karl; can you please provide precise details of your Windows version, and anything unusual about your disk configuration? I know this doesn't happen on any of the installations of Windows 7 that we use for testing (which tend to be the MSDN builds, running on local NTFS disks), so I wonder if there's an icacls bug in a specific build or rev of Windows, or when used on a certain type of filesystem. -- Dave Page Blog: http://pgsnake.blogspot.com Twitter: @pgsnake EnterpriseDB UK: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] [GENERAL] One-click installer, Windows 7 32-bit, and icacls.exe
Dave Page wrote on 03.10.2011 10:11: Karl; can you please provide precise details of your Windows version, and anything unusual about your disk configuration? I know this doesn't happen on any of the installations of Windows 7 that we use for testing (which tend to be the MSDN builds, running on local NTFS disks), so I wonder if there's an icacls bug in a specific build or rev of Windows, or when used on a certain type of filesystem. I have reported this as well some weeks ago. For me this happened on a Windows7 64 bit system that is part of a domain (all current MS patches applied) UAC is turned off, I was logged in as a local administrator (*not* a domain administrator). I have a ProcessMonitor trace that shows the behaviour of what icacls is doing when started by the installer. It is available here: http://www.sql-workbench.net/icacls_trace.zip Regards Thomas -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
[BUGS] bug in dependency - there is possibility to break a system catalog
Hello
our customer reported a broken system dictionary. The following
statements breaks a catalog:
postgres=# CREATE TYPE test_type AS (a integer, b integer);
CREATE TYPE
Time: 61,016 ms
postgres=#
postgres=# CREATE FUNCTION test_func (variadic x text[] =
'{NULL}'::test_type[])
postgres-# RETURNS pg_catalog.void AS $body$ BEGIN END; $body$
LANGUAGE 'plpgsql';
CREATE FUNCTION
Time: 24,637 ms
postgres=#
postgres=# DROP TYPE test_type;
DROP TYPE
Time: 6,824 ms
postgres=# \df
ERROR: cache lookup failed for type 16579
postgres=# select version();
version
──
PostgreSQL 9.2devel on x86_64-unknown-linux-gnu, compiled by gcc
(GCC) 4.6.0 20110603 (Red Hat 4.6.0-10), 64-bit
(1 row)
Time: 2,021 ms
postgres=#
Regards
Pavel Stehule
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #6233: pg_dump hangs with Access Violation C0000005
On 09/29/2011 05:18 AM, Holec wrote: The following bug has been logged online: Bug reference: 6233 Logged by: Holec Email address: ho...@email.cz PostgreSQL version: 8.4.8 Operating system: Windows 7 Description:pg_dump hangs with Access Violation C005 Details: I use pg_dump on Windows 7 with: pg_dump -i -h 192.168.2.2 -p 5432 -U user -F c -b -v -f file.backup mydb Does this crash happen when you back up a different database? Say, if you back up the `template1' database, does it crash then too? Is this a 32-bit or 64-bit install of Windows 7? If 64-bit, are you using a 32-bit or 64-bit build of PostgreSQL? Is there any antivirus software on the machine? If so, what type and version? Does the problem still happen if you turn it off and re-test? -- Craig Ringer Can anybody help me please? Maybe problem with redist msvcr80? With my app I ship only libeay32.dll libiconv-2.dll libintl-8.dll libpq.dll ssleay32.dll zlib1.dll pg_dump.exe pg_restore.exe Pavel Holec -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] [GENERAL] One-click installer, Windows 7 32-bit, and icacls.exe
Thanks Karl. Is SP1 installed? Sachin, Ashesh - anything else you can think of that would be useful? On Mon, Oct 3, 2011 at 1:48 PM, Karl Wright daddy...@gmail.com wrote: Sorry for the delay - it's been a busy morning. The Windows 7 system I'm using is a laptop with a standard basic Nokia image. To the best of my knowledge there have been no OEM modifications of any kind. It describes itself as Windows 7 Enterprise, and says it is 32-bit. That's it. Anything else you'd want me to check? Karl On Mon, Oct 3, 2011 at 4:11 AM, Dave Page dp...@pgadmin.org wrote: On Mon, Oct 3, 2011 at 8:59 AM, Magnus Hagander mag...@hagander.net wrote: On Fri, Sep 30, 2011 at 15:34, Karl Wright daddy...@gmail.com wrote: I saw a thread where somebody saw icacls.exe being called by the one-click installer. I'm having the same thing - the installer has been running for 45 minutes now and is basically going to have to be stopped because I'm out of time waiting for it. Looking at process monitor, it is clear that icacls.exe is going through every file on the entire system and changing its permissions. The process tree indicates that it is a child of the installer, and that it is running the command: icacls C:\ /grant kawright:RX Clearly this won't do at all and should be considered a severe installer bug. If it does, it certainly sounds like a very bad bug. However, according to the documentation for icacls (http://technet.microsoft.com/en-us/library/cc753525(WS.10).aspx), you should use /t to get it to traverse into subdirectories, and clearly it's not doing that. So I wonder why it would go across the whole filesystem - might tbere be a bug in icacls? Yes - that's how it's supposed to work (ie. *not* using /t). The purpose of that code is to ensure that the entire path leading up to the data/installation directories is readable by the users that need it. We've had a number of reported installation failures in the past caused by weirdness where read or execute permissions weren't available for (for example) the service account user, which caused somewhat mysterious failures. Or maybe it has something to do with inheritance? The way inheritance-permissions works on ntfs is, um, let's call it interesting. Maybe it needs to specify the (NP) flag to not propagate inheritance or something? Sachin/Ashesh; can one of you investigate this please? Karl; can you please provide precise details of your Windows version, and anything unusual about your disk configuration? I know this doesn't happen on any of the installations of Windows 7 that we use for testing (which tend to be the MSDN builds, running on local NTFS disks), so I wonder if there's an icacls bug in a specific build or rev of Windows, or when used on a certain type of filesystem. -- Dave Page Blog: http://pgsnake.blogspot.com Twitter: @pgsnake EnterpriseDB UK: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Dave Page Blog: http://pgsnake.blogspot.com Twitter: @pgsnake EnterpriseDB UK: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] [GENERAL] One-click installer, Windows 7 32-bit, and icacls.exe
On Mon, Oct 3, 2011 at 9:42 AM, Thomas Kellerer spam_ea...@gmx.net wrote: Dave Page wrote on 03.10.2011 10:11: Karl; can you please provide precise details of your Windows version, and anything unusual about your disk configuration? I know this doesn't happen on any of the installations of Windows 7 that we use for testing (which tend to be the MSDN builds, running on local NTFS disks), so I wonder if there's an icacls bug in a specific build or rev of Windows, or when used on a certain type of filesystem. I have reported this as well some weeks ago. For me this happened on a Windows7 64 bit system that is part of a domain (all current MS patches applied) UAC is turned off, I was logged in as a local administrator (*not* a domain administrator). I have a ProcessMonitor trace that shows the behaviour of what icacls is doing when started by the installer. It is available here: http://www.sql-workbench.net/icacls_trace.zip Thanks Thomas. That certainly doesn't look like it's doing what it was told to :-s -- Dave Page Blog: http://pgsnake.blogspot.com Twitter: @pgsnake EnterpriseDB UK: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] [GENERAL] One-click installer, Windows 7 32-bit, and icacls.exe
On Mon, Oct 3, 2011 at 2:39 PM, mgo...@isstrucksoftware.net wrote: I am running Windows 7 x64 (version 6.1.7601). My copy is also from the MSDN with latest updates applied. When I get to the end of the postgres install I get a error: Problem running post-install step. Installation may not complete correctly. The database cluster initialisation failed. I very much doubt that s the issue being discussed here. I'd suggest starting a new thread on pgsql-bugs and including your installation logs from %TEMP%. -- Dave Page Blog: http://pgsnake.blogspot.com Twitter: @pgsnake EnterpriseDB UK: http://www.enterprisedb.com The Enterprise PostgreSQL Company top.letterhead
Re: [BUGS] [GENERAL] One-click installer, Windows 7 32-bit, and icacls.exe
text/html; charset="utf-8": Unrecognized inline: top.letterhead
Re: [BUGS] [GENERAL] One-click installer, Windows 7 32-bit, and icacls.exe
I see no evidence that SP1 is installed on this machine. Karl On Mon, Oct 3, 2011 at 9:14 AM, Dave Page dp...@pgadmin.org wrote: Thanks Karl. Is SP1 installed? Sachin, Ashesh - anything else you can think of that would be useful? On Mon, Oct 3, 2011 at 1:48 PM, Karl Wright daddy...@gmail.com wrote: Sorry for the delay - it's been a busy morning. The Windows 7 system I'm using is a laptop with a standard basic Nokia image. To the best of my knowledge there have been no OEM modifications of any kind. It describes itself as Windows 7 Enterprise, and says it is 32-bit. That's it. Anything else you'd want me to check? Karl On Mon, Oct 3, 2011 at 4:11 AM, Dave Page dp...@pgadmin.org wrote: On Mon, Oct 3, 2011 at 8:59 AM, Magnus Hagander mag...@hagander.net wrote: On Fri, Sep 30, 2011 at 15:34, Karl Wright daddy...@gmail.com wrote: I saw a thread where somebody saw icacls.exe being called by the one-click installer. I'm having the same thing - the installer has been running for 45 minutes now and is basically going to have to be stopped because I'm out of time waiting for it. Looking at process monitor, it is clear that icacls.exe is going through every file on the entire system and changing its permissions. The process tree indicates that it is a child of the installer, and that it is running the command: icacls C:\ /grant kawright:RX Clearly this won't do at all and should be considered a severe installer bug. If it does, it certainly sounds like a very bad bug. However, according to the documentation for icacls (http://technet.microsoft.com/en-us/library/cc753525(WS.10).aspx), you should use /t to get it to traverse into subdirectories, and clearly it's not doing that. So I wonder why it would go across the whole filesystem - might tbere be a bug in icacls? Yes - that's how it's supposed to work (ie. *not* using /t). The purpose of that code is to ensure that the entire path leading up to the data/installation directories is readable by the users that need it. We've had a number of reported installation failures in the past caused by weirdness where read or execute permissions weren't available for (for example) the service account user, which caused somewhat mysterious failures. Or maybe it has something to do with inheritance? The way inheritance-permissions works on ntfs is, um, let's call it interesting. Maybe it needs to specify the (NP) flag to not propagate inheritance or something? Sachin/Ashesh; can one of you investigate this please? Karl; can you please provide precise details of your Windows version, and anything unusual about your disk configuration? I know this doesn't happen on any of the installations of Windows 7 that we use for testing (which tend to be the MSDN builds, running on local NTFS disks), so I wonder if there's an icacls bug in a specific build or rev of Windows, or when used on a certain type of filesystem. -- Dave Page Blog: http://pgsnake.blogspot.com Twitter: @pgsnake EnterpriseDB UK: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Dave Page Blog: http://pgsnake.blogspot.com Twitter: @pgsnake EnterpriseDB UK: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] [GENERAL] One-click installer, Windows 7 32-bit, and icacls.exe
Sorry for the delay - it's been a busy morning. The Windows 7 system I'm using is a laptop with a standard basic Nokia image. To the best of my knowledge there have been no OEM modifications of any kind. It describes itself as Windows 7 Enterprise, and says it is 32-bit. That's it. Anything else you'd want me to check? Karl On Mon, Oct 3, 2011 at 4:11 AM, Dave Page dp...@pgadmin.org wrote: On Mon, Oct 3, 2011 at 8:59 AM, Magnus Hagander mag...@hagander.net wrote: On Fri, Sep 30, 2011 at 15:34, Karl Wright daddy...@gmail.com wrote: I saw a thread where somebody saw icacls.exe being called by the one-click installer. I'm having the same thing - the installer has been running for 45 minutes now and is basically going to have to be stopped because I'm out of time waiting for it. Looking at process monitor, it is clear that icacls.exe is going through every file on the entire system and changing its permissions. The process tree indicates that it is a child of the installer, and that it is running the command: icacls C:\ /grant kawright:RX Clearly this won't do at all and should be considered a severe installer bug. If it does, it certainly sounds like a very bad bug. However, according to the documentation for icacls (http://technet.microsoft.com/en-us/library/cc753525(WS.10).aspx), you should use /t to get it to traverse into subdirectories, and clearly it's not doing that. So I wonder why it would go across the whole filesystem - might tbere be a bug in icacls? Yes - that's how it's supposed to work (ie. *not* using /t). The purpose of that code is to ensure that the entire path leading up to the data/installation directories is readable by the users that need it. We've had a number of reported installation failures in the past caused by weirdness where read or execute permissions weren't available for (for example) the service account user, which caused somewhat mysterious failures. Or maybe it has something to do with inheritance? The way inheritance-permissions works on ntfs is, um, let's call it interesting. Maybe it needs to specify the (NP) flag to not propagate inheritance or something? Sachin/Ashesh; can one of you investigate this please? Karl; can you please provide precise details of your Windows version, and anything unusual about your disk configuration? I know this doesn't happen on any of the installations of Windows 7 that we use for testing (which tend to be the MSDN builds, running on local NTFS disks), so I wonder if there's an icacls bug in a specific build or rev of Windows, or when used on a certain type of filesystem. -- Dave Page Blog: http://pgsnake.blogspot.com Twitter: @pgsnake EnterpriseDB UK: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] bug in dependency - there is possibility to break a system catalog
Pavel Stehule pavel.steh...@gmail.com writes: [ we forgot to record dependencies on function default expressions ] Fixed, thanks for the report. regards, tom lane -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
[BUGS] BUG #6237: Hang during install database initialization
The following bug has been logged online: Bug reference: 6237 Logged by: Jim Gray Email address: jim.g...@bull.com PostgreSQL version: 9.1.1 Operating system: Windows Vista Description:Hang during install database initialization Details: The only PostgreSQL release that I can successfully install is 9.0.1 I have tried both 32 and 64 bit Windows installer versions of 9.0.5 and 9.1.1 and all appear to have the same problem. They get to the dialog indicating that database initialization may take a few minutes, and then even after 30 minutes on a recent quad core PC, nothing is happening. No files are created in the data directory. The task manager shows that the Postgres process is not using any CPU time or doing any file I/O. The 9.0.1 install only takes about 10 seconds at this stage. I have tried the installs with anti-virus software disabled, but that didn't help. -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #6237: Hang during install database initialization
On Oct 4, 2011 4:30 AM, Jim Gray jim.g...@bull.com wrote: The following bug has been logged online: Bug reference: 6237 Logged by: Jim Gray Email address: jim.g...@bull.com PostgreSQL version: 9.1.1 Operating system: Windows Vista Description:Hang during install database initialization Details: The only PostgreSQL release that I can successfully install is 9.0.1 I have tried both 32 and 64 bit Windows installer versions of 9.0.5 and 9.1.1 and all appear to have the same problem. They get to the dialog indicating that database initialization may take a few minutes, and then even after 30 minutes on a recent quad core PC, nothing is happening. No files are created in the data directory. The task manager shows that the Postgres process is not using any CPU time or doing any file I/O. The 9.0.1 install only takes about 10 seconds at this stage. I have tried the installs with anti-virus software disabled, but that didn't help. This sounds like it might be another icacls.exe case. Can I get you to check the task manager for icacls while the install is hung? Is your PC on a domain? -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #6234: Memory leak from PQexec
On Oct 4, 2011 2:14 AM, Vikas Mehta vikas.me...@roguewave.com wrote:
Thanks. I found posts on SSL leak reported by purify. However, I couldn't
find any information on the memory leak from PQrequestCancel. Is it a known
issue?
It's essentially the same issue. OpenSSL loads some strings, config
variables etc on demand/first use and doesn't bother to free them. This is
fine because they are only ever loaded once, so there is no continuous
growth with repeated invocations and no leak. Freeing them before program
exit is hard because of ordering issues, so they just let the OS clean it up
with the rest of the process's memory. That's perfectly correct.
If repeat invocations of your problem code within one program session cause
the heap to grow and the reported leak to get bigger / appear more times,
THEN it is a real leak and a real bug.
-Original Message-
From: Craig Ringer [mailto:ring...@ringerc.id.au]
Sent: Friday, September 30, 2011 12:02 AM
To: Vikas Mehta
Cc: pgsql-bugs@postgresql.org
Subject: Re: [BUGS] BUG #6234: Memory leak from PQexec
On 29/09/2011 6:22 AM, Vikas Mehta wrote:
The following bug has been logged online:
Bug reference: 6234
Logged by: Vikas Mehta
Email address: me...@roguewave.com
PostgreSQL version: 8.4.8
Operating system: Windows
Description:Memory leak from PQexec
Details:
Purify shows 448 bytes of memory leaks with PQexec:
[W] Summary of all memory leaks... {448 bytes, 11 blocks}
[W] MLK: Memory leak of 128 bytes from 1 block allocated in
ERR_load_SSL_strings [SSLEAY32.DLL]
It's not a leak, and it's not a bug. Please search the pgsql-general
archives for valgrind or SSL_config.
--
Craig Ringer
Re: [BUGS] BUG #6233: pg_dump hangs with Access Violation C0000005
On 03/10/11 19:42, Pavel Holec wrote: On 09/29/2011 05:18 AM, Holec wrote: The following bug has been logged online: Bug reference: 6233 Logged by: Holec Email address: ho...@email.cz PostgreSQL version: 8.4.8 Operating system: Windows 7 Description:pg_dump hangs with Access Violation C005 Details: I use pg_dump on Windows 7 with: pg_dump -i -h 192.168.2.2 -p 5432 -U user -F c -b -v -f file.backup mydb Does this crash happen when you back up a different database? Say, if you back up the `template1' database, does it crash then too? Is this a 32-bit or 64-bit install of Windows 7? If 64-bit, are you using a 32-bit or 64-bit build of PostgreSQL? Is there any antivirus software on the machine? If so, what type and version? Does the problem still happen if you turn it off and re-test? -- Craig Ringer Can anybody help me please? Honestly, I haven't the foggiest. I didn't see anything dodgy in the DLL list you posted earlier or any of the other info you've provided. To progress, I think you'd need to get a usable backtrace to show how and where the crash happens. Use Visual Studio (or the free Express Edition) or use windbg from Debugging Tools for Windows. Set the symbol path appropriately. Use the debugger to run pg_dump with appropriate arguments, and when it crashes, get a backtrace (stack trace) of the failure. There's some guidance on debugging on Windows here: http://wiki.postgresql.org/wiki/Getting_a_stack_trace_of_a_running_PostgreSQL_backend_on_Windows It's written for getting a stack trace of a BACKEND, and you want to get a stack trace of the CLIENT (pg_dump) so it's not quite the same, but you'll require the same tools and the same initial configuration of the symbol path etc. Instead of attaching to a running postgres.exe though you must run a new pg_dump via the debugger. -- Craig Ringer -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #6234: Memory leak from PQexec
Thanks. I found posts on SSL leak reported by purify. However, I couldn't find
any information on the memory leak from PQrequestCancel. Is it a known issue?
-Original Message-
From: Craig Ringer [mailto:ring...@ringerc.id.au]
Sent: Friday, September 30, 2011 12:02 AM
To: Vikas Mehta
Cc: pgsql-bugs@postgresql.org
Subject: Re: [BUGS] BUG #6234: Memory leak from PQexec
On 29/09/2011 6:22 AM, Vikas Mehta wrote:
The following bug has been logged online:
Bug reference: 6234
Logged by: Vikas Mehta
Email address: me...@roguewave.com
PostgreSQL version: 8.4.8
Operating system: Windows
Description:Memory leak from PQexec
Details:
Purify shows 448 bytes of memory leaks with PQexec:
[W] Summary of all memory leaks... {448 bytes, 11 blocks}
[W] MLK: Memory leak of 128 bytes from 1 block allocated in
ERR_load_SSL_strings [SSLEAY32.DLL]
It's not a leak, and it's not a bug. Please search the pgsql-general archives
for valgrind or SSL_config.
--
Craig Ringer
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
[BUGS] BUG #6239: Looking for a technical contact point for PostgreSQL compatibility issue on Windows8
The following bug has been logged online: Bug reference: 6239 Logged by: Seiko Ishida Email address: v-sei...@microsoft.com PostgreSQL version: 8.2.4 Operating system: Windows 8 Description:Looking for a technical contact point for PostgreSQL compatibility issue on Windows8 Details: Hello, I am a Program Manager with the Ecosystem Engineering team at Microsoft. I am looking for a technical contact point to notify of compatibility issues with PostgreSQL. Could you please connect me to the appropriate individual for this? Regards, Seiko Ishida Microsoft ISV Readiness, EcoSystem Engineering Team Program Manager Ref : 341057 -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #6239: Looking for a technical contact point for PostgreSQL compatibility issue on Windows8
On Mon, Oct 3, 2011 at 8:42 PM, Seiko Ishida v-sei...@microsoft.com wrote: The following bug has been logged online: Bug reference: 6239 Logged by: Seiko Ishida Email address: v-sei...@microsoft.com PostgreSQL version: 8.2.4 Operating system: Windows 8 Description: Looking for a technical contact point for PostgreSQL compatibility issue on Windows8 Details: Hello, I am a Program Manager with the Ecosystem Engineering team at Microsoft. I am looking for a technical contact point to notify of compatibility issues with PostgreSQL. Could you please connect me to the appropriate individual for this? if you think this compatibility issue is a bug of postgresql, this list is just fine otherwise write to pgsql-hack...@postgresql.org... -- Jaime Casanova www.2ndQuadrant.com Professional PostgreSQL: Soporte 24x7 y capacitación -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #6239: Looking for a technical contact point for PostgreSQL compatibility issue on Windows8
On 04/10/11 09:42, Seiko Ishida wrote: PostgreSQL version: 8.2.4 Operating system: Windows 8 From the PostgreSQL release notes: http://www.postgresql.org/docs/8.2/interactive/release-8-2-22.html The PostgreSQL community will stop releasing updates for the 8.2.X release series in December 2011. Users are encouraged to update to a newer release branch soon. In other words, 8.2 will be unsupported before any likely release of Windows 8. Furthermore, 8.2.4 was released on 2007-04-23 and is four and a half years old! You need to a least be testing with 8.2.22, since any fix made to the 8.2 series would get released in 8.2.23 not made retroactively to 8.2.4 . Testing with 9.0 or 9.1 would be much more useful. I am a Program Manager with the Ecosystem Engineering team at Microsoft. I am looking for a technical contact point to notify of compatibility issues with PostgreSQL. Could you please connect me to the appropriate individual for this? Most PostgreSQL work is done on these mailing lists, especially on pgsql-hackers, rather than by direct private correspondance. If there is a specific problem with PostgreSQL 8.2.4 and that problem still exists in the most recent patch release of the 8.2 line, 8.2.22, then please post a follow-up to this list or to the pgsql-hackers list with details on the problem. If you're looking to work directly with a single individual or non-public group to resolve issues with an obsolete version of PostgreSQL then you might want to get in touch with the EnterpriseDB folks. They're focused on commercial support and probably the only ones likely to be interested in very old releases. 8.2.4 is *ANCIENT* and behind on a LOT of bugfix patches, though; you should be testing with 8.2.22, which is the latest in the 8.2 bugfix series, rather than with 8.2.4. Personally I'd be inclined not to care about PostgreSQL 8.2.x on a newly released platform. It's four major releases old and will be officially unsupported any day now. There won't be any old installs to worry about and new installs should be using a current patch release and preferably a more recent major version. -- Craig Ringer -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
