Re: [BUGS] Doc-bug; minor typo in auto_explain documentation

2012-01-27 Thread Magnus Hagander 
On Thu, Jan 26, 2012 at 23:45, Peter Geoghegan  wrote:
> I noticed the following in the auto_explain documentation:
>
> "This can have extremely negative impact on performance."
>
> Surely it should say:
>
> "This can have an extremely negative impact on performance."

Yeah, that seems better. Fix applied.

-- 
 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] Windows x86-64 One-Click Install (9.1.2-1, 9.0.6-1) hangs on "initialising the database cluster" (with work-around)

2012-01-27 Thread Dave Page 
iirc, using %COMSPEC% /c will cause the scripts to run in a visible
command window, which is pretty ugly, and doesn't seem to be necessary
anywhere except on your machine!

What's the output from the "set" command on that box?

On Thu, Jan 26, 2012 at 6:54 PM, Eric Borts  wrote:
> Also, here is a link to the same issue on StackOverflow:
> http://stackoverflow.com/questions/3559719/wscript-shell-run-doesnt-work-consistently
>
> Also solved using %COMSPEC% /c, though it doesn't say why this is a problem.
>
> Cheers,
> Eric
>
>
> On 1/26/2012 11:37 AM, Eric Borts wrote:
>
> On 1/26/2012 1:17 AM, Dave Page wrote:
>
> Dharmendra, can you look into this please?
>
> Eric, is there anything unusual about the configuration of your
> machine? Suffice it to say, this doesn't normally happen.
>
> Hi Dave, I'm guessing the answer to that question is "yes". The machine came
> preinstalled with Norton Internet Security, but this was turned off when I
> ran the install. After further investigation to the .bat file, I realized
> that I am also missing the "Edit" option when I right click a batch file.
>
> I investigated, uninstalled stuff, disabled a lot of stuff in my registry,
> and nearly bricked my computer. After three hours, I'm going to have to ask
> for suggestions. Here's what I found/tried:
>
> 1. uninstalled Norton Internet Security (and rebooted)
> 2. uninstalled Acrobat Reader
> 3. disabled all ContextMenuHandlers by
>     a. renaming HKCR/*/shellex to oldshellex
>     b. renaming HKCR/AllFileSystemsObjects/shellex to oldshellex
>     c. tried, but was unable to rename HKCR/batfile/ShellEx, so renamed
> HKCR/batfile/ShellEx/ContextMenuHandlers to oldContextMenuHandlers
> 4. disabled all non-Microsoft shell extensions using ShellExView
> 5. rebooted - computer bricked (black screen when Windows should be loading)
> 6. booted in safe mode
> 7. tested script (from my original response) and right click.
>     a. no Edit option in batch file context menu
>     b. script hung as before
> 8. Undid steps 3 and 4 in safe mode
> 9. Rebooted - booted into windows properly
> 10. Still no Edit in context menu and script still hangs
>
> I'm open to suggestions. I think it might be related to Edit menu missing
> from my batch file, as this is the only odd thing that I can tell about my
> machine. I have another similar machine (earlier model Vaio) that both has
> the Edit menu and runs the test script successfully. I compared the
> HKCR/batfile registry trees (using TortoiseSVN diff) and they are identical.
> Short of comparing the entire registry I'm at a loss.
>
> Would it be too dangerous to use WScript.Shell.Exec or to use
> WScript.Shell.Run "%COMPSEC% /c" ? This has been an 11 hour struggle for me
> so far, and I know at least a few others have had this same problem. Here is
> a link to my work around on enterprisedb.
>
> Thanks,
> Eric
>
> Reference Links:
> http://www.pcreview.co.uk/forums/edit-print-open-missing-shell-context-menu-cmd-and-bat-files-t2551124.html
> http://windowsxp.mvps.org/slowrightclick.htm
> http://www.nirsoft.net/utils/shexview.html
>
>



-- 
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] Windows x86-64 One-Click Install (9.1.2-1, 9.0.6-1) hangs on "initialising the database cluster" (with work-around)

2012-01-27 Thread Dharmendra Goyal 
Installer works at our end without any issue.

I remember we had considered using "%COMSPEC% /c" earlier but dropped it
because command windows opens up for every new file execution.

On Fri, Jan 27, 2012 at 3:40 PM, Dave Page  wrote:

> iirc, using %COMSPEC% /c will cause the scripts to run in a visible
> command window, which is pretty ugly, and doesn't seem to be necessary
> anywhere except on your machine!
>
> What's the output from the "set" command on that box?
>
> On Thu, Jan 26, 2012 at 6:54 PM, Eric Borts  wrote:
> > Also, here is a link to the same issue on StackOverflow:
> >
> http://stackoverflow.com/questions/3559719/wscript-shell-run-doesnt-work-consistently
> >
> > Also solved using %COMSPEC% /c, though it doesn't say why this is a
> problem.
> >
> > Cheers,
> > Eric
> >
> >
> > On 1/26/2012 11:37 AM, Eric Borts wrote:
> >
> > On 1/26/2012 1:17 AM, Dave Page wrote:
> >
> > Dharmendra, can you look into this please?
> >
> > Eric, is there anything unusual about the configuration of your
> > machine? Suffice it to say, this doesn't normally happen.
> >
> > Hi Dave, I'm guessing the answer to that question is "yes". The machine
> came
> > preinstalled with Norton Internet Security, but this was turned off when
> I
> > ran the install. After further investigation to the .bat file, I realized
> > that I am also missing the "Edit" option when I right click a batch file.
> >
> > I investigated, uninstalled stuff, disabled a lot of stuff in my
> registry,
> > and nearly bricked my computer. After three hours, I'm going to have to
> ask
> > for suggestions. Here's what I found/tried:
> >
> > 1. uninstalled Norton Internet Security (and rebooted)
> > 2. uninstalled Acrobat Reader
> > 3. disabled all ContextMenuHandlers by
> > a. renaming HKCR/*/shellex to oldshellex
> > b. renaming HKCR/AllFileSystemsObjects/shellex to oldshellex
> > c. tried, but was unable to rename HKCR/batfile/ShellEx, so renamed
> > HKCR/batfile/ShellEx/ContextMenuHandlers to oldContextMenuHandlers
> > 4. disabled all non-Microsoft shell extensions using ShellExView
> > 5. rebooted - computer bricked (black screen when Windows should be
> loading)
> > 6. booted in safe mode
> > 7. tested script (from my original response) and right click.
> > a. no Edit option in batch file context menu
> > b. script hung as before
> > 8. Undid steps 3 and 4 in safe mode
> > 9. Rebooted - booted into windows properly
> > 10. Still no Edit in context menu and script still hangs
> >
> > I'm open to suggestions. I think it might be related to Edit menu missing
> > from my batch file, as this is the only odd thing that I can tell about
> my
> > machine. I have another similar machine (earlier model Vaio) that both
> has
> > the Edit menu and runs the test script successfully. I compared the
> > HKCR/batfile registry trees (using TortoiseSVN diff) and they are
> identical.
> > Short of comparing the entire registry I'm at a loss.
> >
> > Would it be too dangerous to use WScript.Shell.Exec or to use
> > WScript.Shell.Run "%COMPSEC% /c" ? This has been an 11 hour struggle for
> me
> > so far, and I know at least a few others have had this same problem.
> Here is
> > a link to my work around on enterprisedb.
> >
> > Thanks,
> > Eric
> >
> > Reference Links:
> >
> http://www.pcreview.co.uk/forums/edit-print-open-missing-shell-context-menu-cmd-and-bat-files-t2551124.html
> > http://windowsxp.mvps.org/slowrightclick.htm
> > http://www.nirsoft.net/utils/shexview.html
> >
> >
>
>
>
> --
> Dave Page
> Blog: http://pgsnake.blogspot.com
> Twitter: @pgsnake
>
> EnterpriseDB UK: http://www.enterprisedb.com
> The Enterprise PostgreSQL Company
>



-- 
Dharmendra Goyal
Senior Software Engineer
EnterpriseDB Corporation
The Enterprise Postgres Company

Phone: +91-20-30589493
Mobile: +91-9552103323

Website: http://www.enterprisedb.com
EnterpriseDB Blog: http://blogs.enterprisedb.com/
Follow us on Twitter: http://www.twitter.com/enterprisedb

This e-mail message (and any attachment) is intended for the use of the
individual or entity to whom it is addressed. This message contains
information from EnterpriseDB Corporation that may be privileged,
confidential, or exempt from disclosure under applicable law. If you are
not the intended recipient or authorized to receive this for the intended
recipient, any use, dissemination, distribution, retention, archiving, or
copying of this communication is strictly prohibited. If you have received
this e-mail in error, please notify the sender immediately by reply e-mail
and delete this message.

Re: [BUGS] BUG #6200: standby bad memory allocations on SELECT

2012-01-27 Thread Robert Haas 
On Mon, Jan 23, 2012 at 3:22 PM, Bridget Frey  wrote:
> Hello,
> We upgraded to postgres 9.1.2 two weeks ago, and we are also experiencing an
> issue that seems very similar to the one reported as bug 6200.  We see
> approximately 2 dozen alloc errors per day across 3 slaves, and we are
> getting one segfault approximately every 3 days.  We did not experience this
> issue before our upgrade (we were on version 8.4, and used skytools for
> replication).
>
> We are attempting to get a core dump on segfault (our last attempt did not
> work due to a config issue for the core dump).  We're also attempting to
> repro the alloc errors on a test setup, but it seems like we may need quite
> a bit of load to trigger the issue.  We're not certain that the alloc issues
> and the sefaults are "the same issue" - but it seems that it may be since
> the OP for bug 6200 sees the same behavior.  We have seen no issues on the
> master, all alloc errors and segfaults have been on the slaves.
>
> We've seen the alloc errors on a few different tables, but most frequently
> on logins.  Rows are added to the logins table one-by-one, and updates
> generally happen one row at a time.  The table is pretty basic, it looks
> like this...
>
> CREATE TABLE logins
> (
>   login_id bigserial NOT NULL,
>   
>   CONSTRAINT logins_pkey PRIMARY KEY (login_id ),
>   
> )
> WITH (
>   FILLFACTOR=80,
>   OIDS=FALSE
> );
>
> The queries that trigger the alloc error on this table look like this (we
> use hibernate hence the funny underscoring...)
> select login0_.login_id as login1_468_0_, l...  from logins login0_ where
> login0_.login_id=$1
>
> The alloc error in the logs looks like this:
> -01-12_080925.log:2012-01-12 17:33:46 PST [16034]: [7-1] [24/25934] ERROR:
> invalid memory alloc request size 18446744073709551613
>
> The alloc error is nearly always for size 18446744073709551613 - though we
> have seen one time where it was a different amount...

Hmm, that number in hex works out to 0xfffd, which makes
it sound an awful lot like the system (for some unknown reason)
attempted to allocate -3 bytes of memory.  I've seen something like
this once before on a customer system running a modified version of
PostgreSQL.  In that case, the problem turned out to be page
corruption.  Circumstances didn't permit determination of the root
cause of the page corruption, however, nor was I able to figure out
exactly how the corruption I saw resulted in an allocation request
like this.  It would be nice to figure out where in the code this is
happening and put in a higher-level guard so that we get a better
error message.

You want want to compile a modified PostgreSQL executable that puts an
extremely long sleep (like a year) just before this error is reported.
 Then, when the system hangs at that point, you can attach a debugger
and pull a stack backtrace.  Or you could insert an abort() at that
point in the code and get a backtrace from the core dump.

-- 
Robert Haas
EnterpriseDB: 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] pgcrypto decrypt_iv() issue

2012-01-27 Thread Marko Kreen 
On Fri, Jan 27, 2012 at 01:37:11AM -0500, Tom Lane wrote:
> Stefan Kaltenbrunner  writes:
> > from some looking at the code in pgcrypto.c it seems to me that the
> > coding pattern in most functions there only checks for errors from the
> > corresponding initialization function, in the case of say decrypt_iv()
> > that means only the IV and the key are actually "validated" because that
> > is what the init function sees(it never sees that data!), if the actual
> > decrypt call fails (because the data is maybe a bit weird^broken) it
> > will happily ignore that and return random data.
> 
> Yeah.  In pg_decrypt() we have
> 
> err = px_combo_init(c, (uint8 *) VARDATA(key), klen, NULL, 0);
> if (!err)
> err = px_combo_decrypt(c, (uint8 *) VARDATA(data), dlen,
>(uint8 *) VARDATA(res), &rlen);
> 
> but in pg_decrypt_iv() it's just
> 
> err = px_combo_init(c, (uint8 *) VARDATA(key), klen,
> (uint8 *) VARDATA(iv), ivlen);
> if (!err)
> px_combo_decrypt(c, (uint8 *) VARDATA(data), dlen,
>  (uint8 *) VARDATA(res), &rlen);
> 
> It looks to me like the result of px_combo_decrypt should be assigned to
> "err" here.  If I make that change, the test case you provide is
> rejected:
> 
> ERROR:  decrypt_iv error: Data not a multiple of block size
> 
> but the module's regression tests all still pass, indicating that this
> sort of case isn't tested.
> 
> pg_encrypt_iv() has the identical usage error with respect to
> px_combo_encrypt.
> 
> Marko, does this look right to you?

Yeah, it should be fixed.  But note that "random data" is part of
decrypt() spec - the validation it can do is a joke.

Its more important to do proper checks in encrypt() to avoid invalid
stored data, but there the recommended modes (CBC, CFB) can work
with any length data, so even there the impact is low.

pgcrypto.c is easily fixable and internal.c has proper checks.
But openssl.c does not.  And I have a bigger openssl.c cleanup
pending.  So I would prefer to add missing checks to cleaned-up
openssl.c and post them together (soonish).

But I'm bit unclear about fate of /contrib cleanup patches vs. 9.2,
so if they won't get in, it's ok to apply quick fixes to current tree,
it won't inconvinience me much.

-- 
marko


-- 
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] pgcrypto decrypt_iv() issue

2012-01-27 Thread Tom Lane 
Marko Kreen  writes:
> pgcrypto.c is easily fixable and internal.c has proper checks.
> But openssl.c does not.  And I have a bigger openssl.c cleanup
> pending.  So I would prefer to add missing checks to cleaned-up
> openssl.c and post them together (soonish).

> But I'm bit unclear about fate of /contrib cleanup patches vs. 9.2,
> so if they won't get in, it's ok to apply quick fixes to current tree,
> it won't inconvinience me much.

I think we should fix and back-patch these two specific bugs.  The
openssl.c change sounds like it might be something for HEAD only.

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] pgcrypto decrypt_iv() issue

2012-01-27 Thread Stefan Kaltenbrunner 
On 01/27/2012 04:20 PM, Marko Kreen wrote:
> On Fri, Jan 27, 2012 at 01:37:11AM -0500, Tom Lane wrote:
>> Stefan Kaltenbrunner  writes:
>>> from some looking at the code in pgcrypto.c it seems to me that the
>>> coding pattern in most functions there only checks for errors from the
>>> corresponding initialization function, in the case of say decrypt_iv()
>>> that means only the IV and the key are actually "validated" because that
>>> is what the init function sees(it never sees that data!), if the actual
>>> decrypt call fails (because the data is maybe a bit weird^broken) it
>>> will happily ignore that and return random data.
>>
>> Yeah.  In pg_decrypt() we have
>>
>> err = px_combo_init(c, (uint8 *) VARDATA(key), klen, NULL, 0);
>> if (!err)
>> err = px_combo_decrypt(c, (uint8 *) VARDATA(data), dlen,
>>(uint8 *) VARDATA(res), &rlen);
>>
>> but in pg_decrypt_iv() it's just
>>
>> err = px_combo_init(c, (uint8 *) VARDATA(key), klen,
>> (uint8 *) VARDATA(iv), ivlen);
>> if (!err)
>> px_combo_decrypt(c, (uint8 *) VARDATA(data), dlen,
>>  (uint8 *) VARDATA(res), &rlen);
>>
>> It looks to me like the result of px_combo_decrypt should be assigned to
>> "err" here.  If I make that change, the test case you provide is
>> rejected:
>>
>> ERROR:  decrypt_iv error: Data not a multiple of block size
>>
>> but the module's regression tests all still pass, indicating that this
>> sort of case isn't tested.
>>
>> pg_encrypt_iv() has the identical usage error with respect to
>> px_combo_encrypt.
>>
>> Marko, does this look right to you?
> 
> Yeah, it should be fixed.  But note that "random data" is part of
> decrypt() spec - the validation it can do is a joke.
> 
> Its more important to do proper checks in encrypt() to avoid invalid
> stored data, but there the recommended modes (CBC, CFB) can work
> with any length data, so even there the impact is low.

I agree - but in my case the input to those functions is actually coming
from external untrusted systems - so if the data is (completely) invalid
really want to get a proper error message instead of random memory content.



> 
> pgcrypto.c is easily fixable and internal.c has proper checks.
> But openssl.c does not.  And I have a bigger openssl.c cleanup
> pending.  So I would prefer to add missing checks to cleaned-up
> openssl.c and post them together (soonish).

hmm so openssl.c has similiar "issues" but you only want to fix them
together with a cleaned larger patch? sounds a bit of a problem for a
backpatch...


Stefan

-- 
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] pgcrypto decrypt_iv() issue

2012-01-27 Thread Marko Kreen 
On Fri, Jan 27, 2012 at 12:13:21PM -0500, Tom Lane wrote:
> Marko Kreen  writes:
> > pgcrypto.c is easily fixable and internal.c has proper checks.
> > But openssl.c does not.  And I have a bigger openssl.c cleanup
> > pending.  So I would prefer to add missing checks to cleaned-up
> > openssl.c and post them together (soonish).
> 
> > But I'm bit unclear about fate of /contrib cleanup patches vs. 9.2,
> > so if they won't get in, it's ok to apply quick fixes to current tree,
> > it won't inconvinience me much.
> 
> I think we should fix and back-patch these two specific bugs.  The
> openssl.c change sounds like it might be something for HEAD only.

Now I looked more in-depth and seems my comments were off - error
detection for encrypt()/decrypt() happens in px.c not in
internal.c/openssl.c.  Latter ones simply validate internal APIs.

So attached patch should be enough to fix the issue.
And it should be quite backportable.

-- 
marko

diff --git a/contrib/pgcrypto/pgcrypto.c b/contrib/pgcrypto/pgcrypto.c
index c758853..a441ca7 100644
--- a/contrib/pgcrypto/pgcrypto.c
+++ b/contrib/pgcrypto/pgcrypto.c
@@ -341,8 +341,8 @@ pg_encrypt_iv(PG_FUNCTION_ARGS)
 	err = px_combo_init(c, (uint8 *) VARDATA(key), klen,
 		(uint8 *) VARDATA(iv), ivlen);
 	if (!err)
-		px_combo_encrypt(c, (uint8 *) VARDATA(data), dlen,
-		 (uint8 *) VARDATA(res), &rlen);
+		err = px_combo_encrypt(c, (uint8 *) VARDATA(data), dlen,
+			   (uint8 *) VARDATA(res), &rlen);
 
 	px_combo_free(c);
 
@@ -395,8 +395,8 @@ pg_decrypt_iv(PG_FUNCTION_ARGS)
 	err = px_combo_init(c, (uint8 *) VARDATA(key), klen,
 		(uint8 *) VARDATA(iv), ivlen);
 	if (!err)
-		px_combo_decrypt(c, (uint8 *) VARDATA(data), dlen,
-		 (uint8 *) VARDATA(res), &rlen);
+		err = px_combo_decrypt(c, (uint8 *) VARDATA(data), dlen,
+			   (uint8 *) VARDATA(res), &rlen);
 
 	px_combo_free(c);
 

-- 
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] pgcrypto decrypt_iv() issue

2012-01-27 Thread Marko Kreen 
On Fri, Jan 27, 2012 at 7:34 PM, Stefan Kaltenbrunner
 wrote:
> On 01/27/2012 04:20 PM, Marko Kreen wrote:
>> On Fri, Jan 27, 2012 at 01:37:11AM -0500, Tom Lane wrote:
>> Yeah, it should be fixed.  But note that "random data" is part of
>> decrypt() spec - the validation it can do is a joke.
>>
>> Its more important to do proper checks in encrypt() to avoid invalid
>> stored data, but there the recommended modes (CBC, CFB) can work
>> with any length data, so even there the impact is low.
>
> I agree - but in my case the input to those functions is actually coming
> from external untrusted systems - so if the data is (completely) invalid
> really want to get a proper error message instead of random memory content.

You *will* get random memory content.  If your app is exploitable with
invalid data, you *will* get exploited.  The decrypt() checks are
more for developer convenience than anything more serious.

Please fix your app to survive invalid data...

-- 
marko

-- 
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] pgcrypto decrypt_iv() issue

2012-01-27 Thread Magnus Hagander 
On Fri, Jan 27, 2012 at 18:54, Marko Kreen  wrote:
> On Fri, Jan 27, 2012 at 7:34 PM, Stefan Kaltenbrunner
>  wrote:
>> On 01/27/2012 04:20 PM, Marko Kreen wrote:
>>> On Fri, Jan 27, 2012 at 01:37:11AM -0500, Tom Lane wrote:
>>> Yeah, it should be fixed.  But note that "random data" is part of
>>> decrypt() spec - the validation it can do is a joke.
>>>
>>> Its more important to do proper checks in encrypt() to avoid invalid
>>> stored data, but there the recommended modes (CBC, CFB) can work
>>> with any length data, so even there the impact is low.
>>
>> I agree - but in my case the input to those functions is actually coming
>> from external untrusted systems - so if the data is (completely) invalid
>> really want to get a proper error message instead of random memory content.
>
> You *will* get random memory content.  If your app is exploitable with
> invalid data, you *will* get exploited.  The decrypt() checks are
> more for developer convenience than anything more serious.

Hold on. I hope there's some misunderstanding here.

I hope you are you saying that feeding random data to the decrypt
functions should be expected to return random data out of previously
free()d areas? Surely you're not?

Obviouly, if you send in invalid data or an invalid key, it will
decrypt into incorrect data, that goes without saying. But it should
still be the same block size and not contain random unrelated memory
blocks, shouldn' it?

-- 
 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] pgcrypto decrypt_iv() issue

2012-01-27 Thread Marko Kreen 
On Fri, Jan 27, 2012 at 8:00 PM, Magnus Hagander  wrote:
> On Fri, Jan 27, 2012 at 18:54, Marko Kreen  wrote:
>> On Fri, Jan 27, 2012 at 7:34 PM, Stefan Kaltenbrunner
>>  wrote:
>>> On 01/27/2012 04:20 PM, Marko Kreen wrote:
 On Fri, Jan 27, 2012 at 01:37:11AM -0500, Tom Lane wrote:
 Yeah, it should be fixed.  But note that "random data" is part of
 decrypt() spec - the validation it can do is a joke.

 Its more important to do proper checks in encrypt() to avoid invalid
 stored data, but there the recommended modes (CBC, CFB) can work
 with any length data, so even there the impact is low.
>>>
>>> I agree - but in my case the input to those functions is actually coming
>>> from external untrusted systems - so if the data is (completely) invalid
>>> really want to get a proper error message instead of random memory content.
>>
>> You *will* get random memory content.  If your app is exploitable with
>> invalid data, you *will* get exploited.  The decrypt() checks are
>> more for developer convenience than anything more serious.
>
> Hold on. I hope there's some misunderstanding here.
>
> I hope you are you saying that feeding random data to the decrypt
> functions should be expected to return random data out of previously
> free()d areas? Surely you're not?
>
> Obviouly, if you send in invalid data or an invalid key, it will
> decrypt into incorrect data, that goes without saying. But it should
> still be the same block size and not contain random unrelated memory
> blocks, shouldn' it?

Yes, it should not contain unrelated data.

-- 
marko

-- 
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] pgcrypto decrypt_iv() issue

2012-01-27 Thread Stefan Kaltenbrunner 
On 01/27/2012 07:06 PM, Marko Kreen wrote:
> On Fri, Jan 27, 2012 at 8:00 PM, Magnus Hagander  wrote:
>> On Fri, Jan 27, 2012 at 18:54, Marko Kreen  wrote:
>>> On Fri, Jan 27, 2012 at 7:34 PM, Stefan Kaltenbrunner
>>>  wrote:
 On 01/27/2012 04:20 PM, Marko Kreen wrote:
> On Fri, Jan 27, 2012 at 01:37:11AM -0500, Tom Lane wrote:
> Yeah, it should be fixed.  But note that "random data" is part of
> decrypt() spec - the validation it can do is a joke.
>
> Its more important to do proper checks in encrypt() to avoid invalid
> stored data, but there the recommended modes (CBC, CFB) can work
> with any length data, so even there the impact is low.

 I agree - but in my case the input to those functions is actually coming
 from external untrusted systems - so if the data is (completely) invalid
 really want to get a proper error message instead of random memory content.
>>>
>>> You *will* get random memory content.  If your app is exploitable with
>>> invalid data, you *will* get exploited.  The decrypt() checks are
>>> more for developer convenience than anything more serious.
>>
>> Hold on. I hope there's some misunderstanding here.
>>
>> I hope you are you saying that feeding random data to the decrypt
>> functions should be expected to return random data out of previously
>> free()d areas? Surely you're not?
>>
>> Obviouly, if you send in invalid data or an invalid key, it will
>> decrypt into incorrect data, that goes without saying. But it should
>> still be the same block size and not contain random unrelated memory
>> blocks, shouldn' it?
> 
> Yes, it should not contain unrelated data.

hmm - see the last example I had in my original report - not sure i
consider the path to pgcrypto.so "related" data and I most definitly do
not expect to get that back from sending invalid data to the database...


Stefan

-- 
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] pgcrypto decrypt_iv() issue

2012-01-27 Thread Marko Kreen 
On Fri, Jan 27, 2012 at 8:10 PM, Stefan Kaltenbrunner
 wrote:
> On 01/27/2012 07:06 PM, Marko Kreen wrote:
>> On Fri, Jan 27, 2012 at 8:00 PM, Magnus Hagander  wrote:
>>> On Fri, Jan 27, 2012 at 18:54, Marko Kreen  wrote:
 On Fri, Jan 27, 2012 at 7:34 PM, Stefan Kaltenbrunner
  wrote:
> On 01/27/2012 04:20 PM, Marko Kreen wrote:
>> On Fri, Jan 27, 2012 at 01:37:11AM -0500, Tom Lane wrote:
>> Yeah, it should be fixed.  But note that "random data" is part of
>> decrypt() spec - the validation it can do is a joke.
>>
>> Its more important to do proper checks in encrypt() to avoid invalid
>> stored data, but there the recommended modes (CBC, CFB) can work
>> with any length data, so even there the impact is low.
>
> I agree - but in my case the input to those functions is actually coming
> from external untrusted systems - so if the data is (completely) invalid
> really want to get a proper error message instead of random memory 
> content.

 You *will* get random memory content.  If your app is exploitable with
 invalid data, you *will* get exploited.  The decrypt() checks are
 more for developer convenience than anything more serious.
>>>
>>> Hold on. I hope there's some misunderstanding here.
>>>
>>> I hope you are you saying that feeding random data to the decrypt
>>> functions should be expected to return random data out of previously
>>> free()d areas? Surely you're not?
>>>
>>> Obviouly, if you send in invalid data or an invalid key, it will
>>> decrypt into incorrect data, that goes without saying. But it should
>>> still be the same block size and not contain random unrelated memory
>>> blocks, shouldn' it?
>>
>> Yes, it should not contain unrelated data.
>
> hmm - see the last example I had in my original report - not sure i
> consider the path to pgcrypto.so "related" data and I most definitly do
> not expect to get that back from sending invalid data to the database...

Yeah, the bug causes return of palloced but uninitialized data.
That needs to be fixed.

-- 
marko

-- 
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 #6200: standby bad memory allocations on SELECT

2012-01-27 Thread Robert Haas 
On Fri, Jan 27, 2012 at 1:31 PM, Bridget Frey  wrote:
> Thanks for the info - that's very helpful.  We had also noted that the alloc
> seems to be -3 bytes.  We have run pg_check and it found no instances of
> corruption. We've also replayed queries that have failed, and have never
> been able to get the same query to fail twice.  In the case you
> investigated, was there permanent page corruption - e.g. you could run the
> same query over and over and get the same result?

Yes.  I observed that the infomask bits on several tuples had somehow
been overwritten by nonsense.  I am not sure whether there were other
kinds of corruption as well - I suspect probably so - but that's the
only one I saw with my own eyes, courtesy of pg_filedump.

> It really does seem like this is an issue either in Hot Standby or very
> closely related to that feature, where there is temporary corruption of a
> btree index that then disappears.  Our master is not experiencing any malloc
> issues, while the 3 slaves get about a dozen per day, despite similar
> workloads.  We haven't have a slave segfault since we set it up to produce a
> core dump, but we're expecting to have that within the next few days
> (assuming we'll continue to get a segfault every 3-4 days).  We're also
> planning to set up one slave that will panic when it gets a malloc issue, as
> you (and other posters on 6400) had suggested.
>
> Thanks again for the help, and we'll keep you posted as we learn more...

The case I investigated involved corruption on the master, and I think
it predated Hot Standby.  However, the symptom is generic enough that
it seems quite possible that there's more than one way for it to
happen.  :-(

-- 
Robert Haas
EnterpriseDB: 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 #6200: standby bad memory allocations on SELECT

2012-01-27 Thread Bridget Frey 
Thanks for the info - that's very helpful.  We had also noted that the
alloc seems to be -3 bytes.  We have run pg_check and it found no instances
of corruption. We've also replayed queries that have failed, and have never
been able to get the same query to fail twice.  In the case you
investigated, was there permanent page corruption - e.g. you could run the
same query over and over and get the same result?

It really does seem like this is an issue either in Hot Standby or very
closely related to that feature, where there is temporary corruption of a
btree index that then disappears.  Our master is not experiencing any
malloc issues, while the 3 slaves get about a dozen per day, despite
similar workloads.  We haven't have a slave segfault since we set it up to
produce a core dump, but we're expecting to have that within the next few
days (assuming we'll continue to get a segfault every 3-4 days).  We're
also planning to set up one slave that will panic when it gets a malloc
issue, as you (and other posters on 6400) had suggested.

Thanks again for the help, and we'll keep you posted as we learn more...
-B

On Fri, Jan 27, 2012 at 6:31 AM, Robert Haas  wrote:

> On Mon, Jan 23, 2012 at 3:22 PM, Bridget Frey 
> wrote:
> > Hello,
> > We upgraded to postgres 9.1.2 two weeks ago, and we are also
> experiencing an
> > issue that seems very similar to the one reported as bug 6200.  We see
> > approximately 2 dozen alloc errors per day across 3 slaves, and we are
> > getting one segfault approximately every 3 days.  We did not experience
> this
> > issue before our upgrade (we were on version 8.4, and used skytools for
> > replication).
> >
> > We are attempting to get a core dump on segfault (our last attempt did
> not
> > work due to a config issue for the core dump).  We're also attempting to
> > repro the alloc errors on a test setup, but it seems like we may need
> quite
> > a bit of load to trigger the issue.  We're not certain that the alloc
> issues
> > and the sefaults are "the same issue" - but it seems that it may be since
> > the OP for bug 6200 sees the same behavior.  We have seen no issues on
> the
> > master, all alloc errors and segfaults have been on the slaves.
> >
> > We've seen the alloc errors on a few different tables, but most
> frequently
> > on logins.  Rows are added to the logins table one-by-one, and updates
> > generally happen one row at a time.  The table is pretty basic, it looks
> > like this...
> >
> > CREATE TABLE logins
> > (
> >   login_id bigserial NOT NULL,
> >   
> >   CONSTRAINT logins_pkey PRIMARY KEY (login_id ),
> >   
> > )
> > WITH (
> >   FILLFACTOR=80,
> >   OIDS=FALSE
> > );
> >
> > The queries that trigger the alloc error on this table look like this (we
> > use hibernate hence the funny underscoring...)
> > select login0_.login_id as login1_468_0_, l...  from logins login0_ where
> > login0_.login_id=$1
> >
> > The alloc error in the logs looks like this:
> > -01-12_080925.log:2012-01-12 17:33:46 PST [16034]: [7-1] [24/25934]
> ERROR:
> > invalid memory alloc request size 18446744073709551613
> >
> > The alloc error is nearly always for size 18446744073709551613 - though
> we
> > have seen one time where it was a different amount...
>
> Hmm, that number in hex works out to 0xfffd, which makes
> it sound an awful lot like the system (for some unknown reason)
> attempted to allocate -3 bytes of memory.  I've seen something like
> this once before on a customer system running a modified version of
> PostgreSQL.  In that case, the problem turned out to be page
> corruption.  Circumstances didn't permit determination of the root
> cause of the page corruption, however, nor was I able to figure out
> exactly how the corruption I saw resulted in an allocation request
> like this.  It would be nice to figure out where in the code this is
> happening and put in a higher-level guard so that we get a better
> error message.
>
> You want want to compile a modified PostgreSQL executable that puts an
> extremely long sleep (like a year) just before this error is reported.
>  Then, when the system hangs at that point, you can attach a debugger
> and pull a stack backtrace.  Or you could insert an abort() at that
> point in the code and get a backtrace from the core dump.
>
> --
> Robert Haas
> EnterpriseDB: http://www.enterprisedb.com
> The Enterprise PostgreSQL Company
>



-- 
Bridget Frey  Director, Data & Analytics Engineering | Redfin

bridget.f...@redfin.com | tel: 206.576.5894

Re: [BUGS] Segfault in backend CTE code

2012-01-27 Thread Phil Sorber 
On Wed, Jan 25, 2012 at 5:13 PM, Tom Lane  wrote:
> Phil Sorber  writes:
>> That helped a lot. I now have a simple test case that I can reliably
>> re-produce the segfault and now also a patch that fixes it.
>
> [ pokes at that... ]  Hmm.  I think what this proves is that that
> optimization in EvalPlanQualStart is just too cute for its own good,
> and that the only safe fix is to take it out.  That code path is
> (obviously) none too well tested, so we should not have it setting
> up execution tree structures that are not like those used normally.
> It's just begging for trouble.

I played around with removing the optimization, but there are other
pieces further down the line that are upset but having a ModifyTable
node in the execution tree. Specifically this:

http://git.postgresql.org/gitweb/?p=postgresql.git;a=blob;f=src/backend/executor/nodeModifyTable.c;h=cf32dc569037f710ce6c43c4c93ee3a10cabe085;hb=389af951552ff2209eae3e62fa147fef12329d4f#l900

Not sure at all how to proceed from there so I am deferring. Perhaps
the original authors can be asked to weigh in? We changed our writable
CTE queries to update/insert loops so this is no longer a blocker for
us.

>
>                        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] Windows x86-64 One-Click Install (9.1.2-1, 9.0.6-1) hangs on "initialising the database cluster" (with work-around)

2012-01-27 Thread Eric Borts 

Regarding my final point:

"Similarly, you may prefer to have the default action for a batch file 
(.bat) changed to Edit instead of Open. Double-clicking the file will 
not run the commands in the file, and if users want to run the file, 
they can use the*Open*command on the shortcut menu."

http://support.microsoft.com/kb/320036

This advice would be likely to hang the PostgreSQL installer.

Cheers,
Eric


On 1/27/2012 12:32 PM, Eric Borts wrote:

Hi Dave and Dharmendra,

It is not the "%COMSPEC% /c" call that causes the window to popup, but 
the WindowStyle parameter to WShell.Run (see Table 3.9 in MS TechNet 
WSH Objects / Running Programs 
). Setting 
WindowStyle to "0" creates a hidden window. This is how the code in 
the installer is currently written. Setting it to "1" creates a 
visible window. This happens when using "%COMSPEC% /c" or when calling 
the batch file directly.


Here is a another site recommending 
 
the use of "%COMSPEC% /c" with a "0" second parameter, along with a 
note about the window (in)visibility:


"[...] do not run any command that raises a prompt, dialog, msgbox 
or any other GUI. This [...] could hang your entire system (since the 
invisible GUI will be waiting for a reply [...]"


Test code is attached that demonstrates using COMSPEC with a "0" 
versus a "1".


Output from SET command is also attached. Note that I've verified that 
this problem still occurs in Safe Mode.


Any other suggestions? I've also posted to StackOverflow 
 
for adivce.


A separate line of reasoning for using COMSPEC is that the calling of 
the .bat directly assumes that default action is to execute the batch 
file. If a user has modified their default .bat actions (which I have 
not), the postgres installer will fail. Using COMSPEC will avoid that 
pitfall.


I'll keep you posted if I discover why my machine doesn't execute 
batch files by default, or how it ended up in this condition. The 
computer is only about 2 months old, so I haven't had *that* much time 
to overwhelm it with installs.


Eric

[BUGS] Example in plpgsql docs can lead to infinite loop

2012-01-27 Thread Phil Sorber 
http://www.postgresql.org/docs/devel/static/plpgsql-control-structures.html#PLPGSQL-UPSERT-EXAMPLE

This example can lead to an infinite loop if there is another column
that has a unique key constraint on it in addition to the primary key
and someone tries to execute the function with a unique primary key
but a duplicate value for the column with the unique constraint.

CREATE TABLE db (a INT PRIMARY KEY, b TEXT UNIQUE);

CREATE FUNCTION merge_db(key INT, data TEXT) RETURNS VOID AS
$$
BEGIN
LOOP
-- first try to update the key
UPDATE db SET b = data WHERE a = key;
IF found THEN
RETURN;
END IF;
-- not there, so try to insert the key
-- if someone else inserts the same key concurrently,
-- we could get a unique-key failure
BEGIN
INSERT INTO db(a,b) VALUES (key, data);
RETURN;
EXCEPTION WHEN unique_violation THEN
-- Do nothing, and loop to try the UPDATE again.
END;
END LOOP;
END;
$$
LANGUAGE plpgsql;

SELECT merge_db(1, 'david');
SELECT merge_db(2, 'david');

The update effects no rows because the primary key value doesn't exist
and the insert fails because the unique key constraint fails but the
exception handling ignores the error. It almost seems like there
should be a primary_key_violation exception type to distinguish, but
all I am suggesting right now is that we make a note of that case in
the docs so that fewer people get stung by this. I have attached a
patch with some suggested wording.
diff --git a/doc/src/sgml/plpgsql.sgml b/doc/src/sgml/plpgsql.sgml
new file mode 100644
index 5a1e33f..6c203b5
*** a/doc/src/sgml/plpgsql.sgml
--- b/doc/src/sgml/plpgsql.sgml
*** SELECT merge_db(1, 'dennis');
*** 2561,2567 
  
   This coding assumes the unique_violation error is caused by
   the INSERT, and not by, say, an INSERT in a
!  trigger function on the table.  More safety could be had by using the
   features discussed next to check that the trapped error was the one
   expected.
  
--- 2561,2569 
  
   This coding assumes the unique_violation error is caused by
   the INSERT, and not by, say, an INSERT in a
!  trigger function on the table.  It also assumes that the
!  unique_violation error is caused by the primary key and not
!  another unique constraint.  More safety could be had by using the
   features discussed next to check that the trapped error was the one
   expected.
  

-- 
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] Windows x86-64 One-Click Install (9.1.2-1, 9.0.6-1) hangs on "initialising the database cluster" (with work-around)

2012-01-27 Thread Eric Borts 

The installation now runs successfully after deleting that registry key.

In addition, I tried changing the default action on batch files from 
"Open" to "Edit" using the registry (Windows 7). Double-clicking a file 
opens it in Notepad, but the installation runs successfully. So it looks 
like the UserChoice registry key, however it got there, is the essence 
of the problem.


Which, of course, %COMSPEC% /c would avoid because the program handling 
batch files is explicit.


Thanks,
Eric

On 1/27/2012 1:16 PM, Eric Borts wrote:
I found the problem with my computer here 
. 
It turns out this registry entry was causing my problem:


HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\FileExts\.bat
\UserChoice
Progid REG_SZ (Applications\cmd.exe)

Deleting the \UserChoice key restored my context menu and ability to 
run a ".bat" directly instead of using %COMSPEC%.


I am going to un-install an re-install postgres to verify that this 
solves my installation issues.


Eric







On 1/27/2012 12:41 PM, Eric Borts wrote:

Regarding my final point:

"Similarly, you may prefer to have the default action for a batch 
file (.bat) changed to Edit instead of Open. Double-clicking the file 
will not run the commands in the file, and if users want to run the 
file, they can use the*Open*command on the shortcut menu."

http://support.microsoft.com/kb/320036

This advice would be likely to hang the PostgreSQL installer.

Cheers,
Eric


On 1/27/2012 12:32 PM, Eric Borts wrote:

Hi Dave and Dharmendra,

It is not the "%COMSPEC% /c" call that causes the window to popup, 
but the WindowStyle parameter to WShell.Run (see Table 3.9 in MS 
TechNet WSH Objects / Running Programs 
). Setting 
WindowStyle to "0" creates a hidden window. This is how the code in 
the installer is currently written. Setting it to "1" creates a 
visible window. This happens when using "%COMSPEC% /c" or when 
calling the batch file directly.


Here is a another site recommending 
 
the use of "%COMSPEC% /c" with a "0" second parameter, along with a 
note about the window (in)visibility:


"[...] do not run any command that raises a prompt, dialog, 
msgbox or any other GUI. This [...] could hang your entire system 
(since the invisible GUI will be waiting for a reply [...]"


Test code is attached that demonstrates using COMSPEC with a "0" 
versus a "1".


Output from SET command is also attached. Note that I've verified 
that this problem still occurs in Safe Mode.


Any other suggestions? I've also posted to StackOverflow 
 
for adivce.


A separate line of reasoning for using COMSPEC is that the calling 
of the .bat directly assumes that default action is to execute the 
batch file. If a user has modified their default .bat actions (which 
I have not), the postgres installer will fail. Using COMSPEC will 
avoid that pitfall.


I'll keep you posted if I discover why my machine doesn't execute 
batch files by default, or how it ended up in this condition. The 
computer is only about 2 months old, so I haven't had *that* much 
time to overwhelm it with installs.


Eric

Re: [BUGS] Windows x86-64 One-Click Install (9.1.2-1, 9.0.6-1) hangs on "initialising the database cluster" (with work-around)

2012-01-27 Thread Eric Borts 
I found the problem with my computer here 
. 
It turns out this registry entry was causing my problem:


HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\FileExts\.bat
\UserChoice
Progid REG_SZ (Applications\cmd.exe)

Deleting the \UserChoice key restored my context menu and ability to run 
a ".bat" directly instead of using %COMSPEC%.


I am going to un-install an re-install postgres to verify that this 
solves my installation issues.


Eric







On 1/27/2012 12:41 PM, Eric Borts wrote:

Regarding my final point:

"Similarly, you may prefer to have the default action for a batch file 
(.bat) changed to Edit instead of Open. Double-clicking the file will 
not run the commands in the file, and if users want to run the file, 
they can use the*Open*command on the shortcut menu."

http://support.microsoft.com/kb/320036

This advice would be likely to hang the PostgreSQL installer.

Cheers,
Eric


On 1/27/2012 12:32 PM, Eric Borts wrote:

Hi Dave and Dharmendra,

It is not the "%COMSPEC% /c" call that causes the window to popup, 
but the WindowStyle parameter to WShell.Run (see Table 3.9 in MS 
TechNet WSH Objects / Running Programs 
). Setting 
WindowStyle to "0" creates a hidden window. This is how the code in 
the installer is currently written. Setting it to "1" creates a 
visible window. This happens when using "%COMSPEC% /c" or when 
calling the batch file directly.


Here is a another site recommending 
 
the use of "%COMSPEC% /c" with a "0" second parameter, along with a 
note about the window (in)visibility:


"[...] do not run any command that raises a prompt, dialog, 
msgbox or any other GUI. This [...] could hang your entire system 
(since the invisible GUI will be waiting for a reply [...]"


Test code is attached that demonstrates using COMSPEC with a "0" 
versus a "1".


Output from SET command is also attached. Note that I've verified 
that this problem still occurs in Safe Mode.


Any other suggestions? I've also posted to StackOverflow 
 
for adivce.


A separate line of reasoning for using COMSPEC is that the calling of 
the .bat directly assumes that default action is to execute the batch 
file. If a user has modified their default .bat actions (which I have 
not), the postgres installer will fail. Using COMSPEC will avoid that 
pitfall.


I'll keep you posted if I discover why my machine doesn't execute 
batch files by default, or how it ended up in this condition. The 
computer is only about 2 months old, so I haven't had *that* much 
time to overwhelm it with installs.


Eric

Re: [BUGS] Windows x86-64 One-Click Install (9.1.2-1, 9.0.6-1) hangs on "initialising the database cluster" (with work-around)

2012-01-27 Thread Dharmendra Goyal 
On Sat, Jan 28, 2012 at 2:17 AM, Eric Borts  wrote:

>  The installation now runs successfully after deleting that registry key.
>
> In addition, I tried changing the default action on batch files from
> "Open" to "Edit" using the registry (Windows 7). Double-clicking a file
> opens it in Notepad, but the installation runs successfully. So it looks
> like the UserChoice registry key, however it got there, is the essence of
> the problem.
>
> Which, of course, %COMSPEC% /c would avoid because the program handling
> batch files is explicit.
>
Nice analysis Eric. ANy idea why (which program set this) this particular
registry was set.

Dave, shall we consider using "%COMSPEC% /c" with 0 as second parameter..??

>
> Thanks,
> Eric
>
>
> On 1/27/2012 1:16 PM, Eric Borts wrote:
>
> I found the problem with my computer 
> here.
> It turns out this registry entry was causing my problem:
>
> HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\FileExts\.bat
> \UserChoice
> Progid REG_SZ (Applications\cmd.exe)
>
> Deleting the \UserChoice key restored my context menu and ability to run a
> ".bat" directly instead of using %COMSPEC%.
>
> I am going to un-install an re-install postgres to verify that this solves
> my installation issues.
>
> Eric
>
>
>
>
>
>
>
> On 1/27/2012 12:41 PM, Eric Borts wrote:
>
> Regarding my final point:
>
> "Similarly, you may prefer to have the default action for a batch file
> (.bat) changed to Edit instead of Open. Double-clicking the file will not
> run the commands in the file, and if users want to run the file, they can
> use the *Open* command on the shortcut menu."
> http://support.microsoft.com/kb/320036
>
> This advice would be likely to hang the PostgreSQL installer.
>
> Cheers,
> Eric
>
>
> On 1/27/2012 12:32 PM, Eric Borts wrote:
>
> Hi Dave and Dharmendra,
>
> It is not the "%COMSPEC% /c" call that causes the window to popup, but the
> WindowStyle parameter to WShell.Run (see Table 3.9 in MS TechNet WSH
> Objects / Running 
> Programs).
> Setting WindowStyle to "0" creates a hidden window. This is how the code in
> the installer is currently written. Setting it to "1" creates a visible
> window. This happens when using "%COMSPEC% /c" or when calling the batch
> file directly.
>
> Here is a another site 
> recommendingthe
>  use of "%COMSPEC% /c" with a "0" second parameter, along with a note
> about the window (in)visibility:
>
> "[...] do not run any command that raises a prompt, dialog, msgbox or
> any other GUI. This [...] could hang your entire system (since the
> invisible GUI will be waiting for a reply [...]"
>
> Test code is attached that demonstrates using COMSPEC with a "0" versus a
> "1".
>
> Output from SET command is also attached. Note that I've verified that
> this problem still occurs in Safe Mode.
>
> Any other suggestions? I've also posted to 
> StackOverflowfor
>  adivce.
>
> A separate line of reasoning for using COMSPEC is that the calling of the
> .bat directly assumes that default action is to execute the batch file. If
> a user has modified their default .bat actions (which I have not), the
> postgres installer will fail. Using COMSPEC will avoid that pitfall.
>
> I'll keep you posted if I discover why my machine doesn't execute batch
> files by default, or how it ended up in this condition. The computer is
> only about 2 months old, so I haven't had *that* much time to overwhelm it
> with installs.
>
> Eric
>
>
>
>
>


-- 
Dharmendra Goyal
Senior Software Engineer
EnterpriseDB Corporation
The Enterprise Postgres Company

Phone: +91-20-30589493
Mobile: +91-9552103323

Website: http://www.enterprisedb.com
EnterpriseDB Blog: http://blogs.enterprisedb.com/
Follow us on Twitter: http://www.twitter.com/enterprisedb

This e-mail message (and any attachment) is intended for the use of the
individual or entity to whom it is addressed. This message contains
information from EnterpriseDB Corporation that may be privileged,
confidential, or exempt from disclosure under applicable law. If you are
not the intended recipient or authorized to receive this for the intended
recipient, any use, dissemination, distribution, retention, archiving, or
copying of this communication is strictly prohibited. If you have received
this e-mail in error, please notify the sender immediately by reply e-mail
and delete this message.

Re: [BUGS] pgcrypto decrypt_iv() issue

2012-01-27 Thread Tom Lane 
Marko Kreen  writes:
> On Fri, Jan 27, 2012 at 12:13:21PM -0500, Tom Lane wrote:
>> I think we should fix and back-patch these two specific bugs.  The
>> openssl.c change sounds like it might be something for HEAD only.

> Now I looked more in-depth and seems my comments were off - error
> detection for encrypt()/decrypt() happens in px.c not in
> internal.c/openssl.c.  Latter ones simply validate internal APIs.

> So attached patch should be enough to fix the issue.

Applied, thanks.

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