Re: [BUGS] BUG #5485: Microsoft VC++ exception during postgres instalation
On 31/05/2010 4:01 PM, Jakub Bogacz wrote: The following bug has been logged online: Bug reference: 5485 Logged by: Jakub Bogacz Email address: jakubbog...@o2.pl PostgreSQL version: 8.4.1, 9.0.0 Operating system: Windows 7 Description:Microsoft VC++ exception during postgres instalation Details: Hi, Since I've instaled W7, I can't install postgres DB. After run a instaler, I always get an error:An error occured executing the Microsoft VC++ runtime installer. Works for me - I just installed Pg 9.0.0beta1 on my new win7 install today. (Thanks Dave!) Are you running Windows 7 32-bit or Windows 7 64-bit? Which edition? (Home, Pro, Ultimate, etc) Is this an upgrade from an older Windows version (and if so, which one) or is it a clean install? If it's an upgrade, did you have a version of PostgreSQL installed at some previous time? Is your Windows 7 install a standard Microsoft one, or was it a preinstall/restore by a hardware manufacturer? Are you running an Administrator account or a basic user account? (if you're using the account created with the operating system install, it's an admin account). Is UAC at the default settings, or have you changed them? Do you have a virus scanner installed? If so, which one? If you download and install the MSVC++ 2005 runtime redist ( http://www.microsoft.com/Downloads/details.aspx?familyid=200B2FD9-AE1A-4A14-984D-389C36F85647displaylang=en ) separately, are you then able to install Pg? -- 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 #5485: Microsoft VC++ exception during postgres instalation
As a workaround you can run the installer with a CLI option '--install_runtimes 0' which will skip the VC++ runtimes installation, However if your system doesn;t have those runtimes installation will fail subsequently in the later stages. From the the installation logs found in %TEMP%, you can find the error code returned by the VC++ runtimes installer which will be helpful in knowing why it failed on your system. On 5/31/10 1:31 PM, Jakub Bogacz wrote: The following bug has been logged online: Bug reference: 5485 Logged by: Jakub Bogacz Email address: jakubbog...@o2.pl PostgreSQL version: 8.4.1, 9.0.0 Operating system: Windows 7 Description:Microsoft VC++ exception during postgres instalation Details: Hi, Since I've instaled W7, I can't install postgres DB. After run a instaler, I always get an error:An error occured executing the Microsoft VC++ runtime installer. Please some help. -- Regards, Sachin Srivastava EnterpriseDB http://www.enterprisedb.com, the Enterprise Postgres http://www.enterprisedb.com company.
Re: [BUGS] BUG #5469: regexp_matches() has poor behaviour and more poor documentation
Daniele Varrazzo wrote: On Sun, May 30, 2010 at 4:45 AM, Robert Haas robertmh...@gmail.com wrote: On Sat, May 29, 2010 at 5:00 PM, Bruce Momjian br...@momjian.us wrote: I have updated the patch, attached, to clarify that this returns text arrays, and that you can force it to always return one row using COALESCE() and a '|' pattern (the later suggested by Daniele Varrazzo). I don't find this part to be something we should include in the documentation. ?If we want to include a workaround, how about defining a non-SRF that just calls the SRF and returns the first row? I think a documentation correction could be backported without problem to all the currently maintained version of PostgreSQL (which would be of good google value, as very often google searches lands you to previous releases doc pages), whereas a easier to use function would be a new feature and as such could only be introduced in 9.0 or even 9.1. While you might have had this problem, it is not a common problem so not something we are about to take tons of time addressing. -- Bruce Momjian br...@momjian.ushttp://momjian.us EnterpriseDB http://enterprisedb.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] BUG #5416: int4inc() is wrong
John Regehr wrote: Hi Tom, If you can show me rewrites of all the basic arithmetic operations that detect overflow in full compliance with the C standard, and are readable, portable, and efficient, I'm all ears. These are the best ones that I know of: https://www.securecoding.cert.org/confluence/display/seccode/INT32-C.+Ensure+that+operations+on+signed+integers+do+not+result+in+overflow Even if you dislike these, please take a look at the safety checks for shifts. The current postgresql shift functions need to be strengthened, and it is easy to do. Added to TODO: Consider improving overflow detection * http://archives.postgresql.org/message-id/4bc66a57.2030...@cs.utah.edu -- Bruce Momjian br...@momjian.ushttp://momjian.us EnterpriseDB http://enterprisedb.com + None of us is going to be here forever. + -- 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 #5416: int4inc() is wrong
Bruce Momjian br...@momjian.us writes: Consider improving overflow detection * http://archives.postgresql.org/message-id/4bc66a57.2030...@cs.utah.edu I did look at those at the time, and saw absolutely no reason to prefer them over what we do now. 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
Re: [BUGS] BUG #5416: int4inc() is wrong
Tom Lane wrote: Bruce Momjian br...@momjian.us writes: Consider improving overflow detection * http://archives.postgresql.org/message-id/4bc66a57.2030...@cs.utah.edu I did look at those at the time, and saw absolutely no reason to prefer them over what we do now. OK, removed from TODO. -- Bruce Momjian br...@momjian.ushttp://momjian.us EnterpriseDB http://enterprisedb.com + None of us is going to be here forever. + -- 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 CREATE FUNCTION with character type (CONFIRMED BUG)
Pavel Stehule wrote: 2010/4/15 Tom Lane t...@sss.pgh.pa.us: Pavel Stehule pavel.steh...@gmail.com writes: I think, so RETURNS TABLE can be modified for returning typmode without significant problems - this function is called in table context and I don't see any problematic use case. RETURNS TABLE is just a shorthand for some OUT parameters. ?I don't believe it's either easy or a good idea to make it work differently from every other function-argument-or-result case. I don't know now. It minimally have to be documented Can you suggest some documentation? -- Bruce Momjian br...@momjian.ushttp://momjian.us EnterpriseDB http://enterprisedb.com + None of us is going to be here forever. + -- 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 #5487: dblink failed with 63 bytes connection names
The following bug has been logged online:
Bug reference: 5487
Logged by: Takahiro Itagaki
Email address: itagaki.takah...@oss.ntt.co.jp
PostgreSQL version: 9.0beta1
Operating system: Linux
Description:dblink failed with 63 bytes connection names
Details:
Contib/dblink module seems to have a bug in handling
connection names in NAMEDATALEN-1 bytes.
It cannot use exiting connections with 63 bytes name
in some cases. For example, we cannot disconnect
such connections. Also, we can reconnect with the
same name and will have two connections with the name.
=# SELECT dblink_connect(repeat('1234567890', 6) || 'ABC',
'host=localhost');
dblink_connect
OK
(1 row)
=# SELECT dblink_get_connections();
dblink_get_connections
---
{123456789012345678901234567890123456789012345678901234567890ABC}
(1 row)
=# SELECT dblink_disconnect(repeat('1234567890', 6) || 'ABC');
ERROR: connection
123456789012345678901234567890123456789012345678901234567890ABC not
available
--
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 #5487: dblink failed with 63 bytes connection names
Takahiro Itagaki itagaki.takah...@oss.ntt.co.jp wrote:
Bug reference: 5487
Logged by: Takahiro Itagaki
Email address: itagaki.takah...@oss.ntt.co.jp
Description:dblink failed with 63 bytes connection names
Details:
Contib/dblink module seems to have a bug in handling
connection names in NAMEDATALEN-1 bytes.
Here is a patch to fix the bug. I think it comes from wrong usage
of snprintf(NAMEDATALEN - 1). It just copies 62 bytes + \0.
In addition, it should be safe to use pg_mbcliplen() to truncate
extra bytes in connection names because we might return invalid
text when a multibyte character is at 62 or 63 bytes.
Note that the fix should be ported to previous versions, too.
It cannot use exiting connections with 63 bytes name
in some cases. For example, we cannot disconnect
such connections. Also, we can reconnect with the
same name and will have two connections with the name.
=# SELECT dblink_connect(repeat('1234567890', 6) || 'ABC',
'host=localhost');
dblink_connect
OK
(1 row)
=# SELECT dblink_get_connections();
dblink_get_connections
---
{123456789012345678901234567890123456789012345678901234567890ABC}
(1 row)
=# SELECT dblink_disconnect(repeat('1234567890', 6) || 'ABC');
ERROR: connection
123456789012345678901234567890123456789012345678901234567890ABC not
available
Regards,
---
Takahiro Itagaki
NTT Open Source Software Center
dblink_63bytes.patch
Description: Binary data
--
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 CREATE FUNCTION with character type (CONFIRMED BUG)
2010/5/31 Bruce Momjian br...@momjian.us: Pavel Stehule wrote: 2010/4/15 Tom Lane t...@sss.pgh.pa.us: Pavel Stehule pavel.steh...@gmail.com writes: I think, so RETURNS TABLE can be modified for returning typmode without significant problems - this function is called in table context and I don't see any problematic use case. RETURNS TABLE is just a shorthand for some OUT parameters. ?I don't believe it's either easy or a good idea to make it work differently from every other function-argument-or-result case. I don't know now. It minimally have to be documented Can you suggest some documentation? some like typmod in declared parameters are ignored - so returned table can not be same as table declared by CREATE STATEMENT. Pavel -- Bruce Momjian br...@momjian.us http://momjian.us EnterpriseDB http://enterprisedb.com + None of us is going to be here forever. + -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
