[BUGS] BUG #7526: An error occured executing the Microsoft VC++ runtime installer
The following bug has been logged on the website: Bug reference: 7526 Logged by: Dan Email address: s3n_...@yahoo.com PostgreSQL version: 8.4.7 Operating system: Windows Vista Home Premium Description: Please help me with this error, i tried everything i found for this issue but didn't work for me , If i try to install the latest version 9.1.5 i will get another error : unable to write inside TEMP environment variable path you can find below the log file for 8.4.7 version: Log started 09/09/12 at 13:29:37 Preferred installation mode : unattended Trying to init installer in mode unattended Mode unattended successfully initialized Could not find registry key HKEY_LOCAL_MACHINE\SOFTWARE\PostgreSQL\Installations\postgresql-8.4 Data Directory. Setting variable iDataDirectory to empty value Could not find registry key HKEY_LOCAL_MACHINE\SOFTWARE\PostgreSQL\Installations\postgresql-8.4 Base Directory. Setting variable iBaseDirectory to empty value Could not find registry key HKEY_LOCAL_MACHINE\SOFTWARE\PostgreSQL\Installations\postgresql-8.4 Service ID. Setting variable iServiceName to empty value Could not find registry key HKEY_LOCAL_MACHINE\SOFTWARE\PostgreSQL\Installations\postgresql-8.4 Service Account. Setting variable iServiceAccount to empty value Could not find registry key HKEY_LOCAL_MACHINE\SOFTWARE\PostgreSQL\Installations\postgresql-8.4 Super User. Setting variable iSuperuser to empty value Could not find registry key HKEY_LOCAL_MACHINE\SOFTWARE\PostgreSQL\Installations\postgresql-8.4 Branding. Setting variable iBranding to empty value Could not find registry key HKEY_LOCAL_MACHINE\SOFTWARE\PostgreSQL\Installations\postgresql-8.4 Version. Setting variable brandingVer to empty value Could not find registry key HKEY_LOCAL_MACHINE\SOFTWARE\PostgreSQL\Installations\postgresql-8.4 Shortcuts. Setting variable iShortcut to empty value Could not find registry key HKEY_LOCAL_MACHINE\SOFTWARE\PostgreSQL\Installations\postgresql-8.4 DisableStackBuilder. Setting variable iDisableStackBuilder to empty value [13:29:39] Existing base directory: [13:29:39] Existing data directory: [13:29:39] Using branding: PostgreSQL 8.4 [13:29:39] Using Super User: postgres and Service Account: postgres [13:29:39] Using Service Name: postgresql-8.4 Executing cscript //NoLogo "C:\Users\Dan\AppData\Local\Temp\postgresql_installer\installruntimes.vbs" "C:\Users\Dan\AppData\Local\Temp\postgresql_installer\vcredist_x86.exe" Script exit code: 1 Script output: CScript Error: Can't find script engine "VBScript" for script "C:\Users\Dan\AppData\Local\Temp\postgresql_installer\installruntimes.vbs". Script stderr: Program ended with an error exit code An error occured executing the Microsoft VC++ runtime installer. An error occured executing the Microsoft VC++ runtime installer. Thank you in advance Dan -- 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 #7527: PgAdmin 1.14.3 fails
The following bug has been logged on the website: Bug reference: 7527 Logged by: Ronaldo Souza Email address: rona...@gpiti.com.br PostgreSQL version: 9.0.6 Operating system: Windows XP Description: I'd like to debug postgresql functions, set postgresql.conf with shared_preload_libraries = '$libdir/plugins/plugin_debugger.dll' and run pldbgapi.sql, restarded BD, but the debugger doesn't work, after i input the parameters function it show me the message: an error has occurred! and then the PgAdmin 1.14.3 close. Do you have any idea what can i do? -- 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 #7516: PL/Perl crash
Marko Tiikkaja writes:
> On 03/09/2012 18:06, Tom Lane wrote:
>> Hm. Is it possible that the prepared statement recursively called the
>> *same* plperl function? And that somebody did a CREATE OR REPLACE on
>> that function meanwhile?
> No, that doesn't seem possible in this case. The function calls some
> prepared statements repeatedly, but no recursion should occur.
Hm. Well, I can definitely reproduce a segfault using this example:
CREATE OR REPLACE FUNCTION self_modify(INTEGER) RETURNS INTEGER AS $$
spi_exec_query('CREATE OR REPLACE FUNCTION self_modify(INTEGER) RETURNS
INTEGER AS \'return $_[0] * 3;\' LANGUAGE plperl;');
spi_exec_query('select self_modify(42) AS a');
return $_[0] * 2;
$$ LANGUAGE plperl;
select self_modify(42);
The crash is 100% reproducible if you tweak plperl like this:
diff --git a/src/pl/plperl/plperl.c b/src/pl/plperl/plperl.c
index bfa805d..307874c 100644
--- a/src/pl/plperl/plperl.c
+++ b/src/pl/plperl/plperl.c
@@ -2393,7 +2393,7 @@ validate_plperl_function(plperl_proc_ptr *proc_ptr, HeapTu
activate_interpreter(oldinterp);
}
free(prodesc->proname);
- free(prodesc);
+ memset(prodesc, 0, sizeof(plperl_proc_desc));
}
return false;
Without that it's probabilistic, since the subsequent malloc in
compile_plperl_function is likely to realloc the exact same space.
So I think we need to institute a reference counting scheme for
the plperl_proc_desc records ...
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 #7516: PL/Perl crash
I wrote:
> Hm. Well, I can definitely reproduce a segfault using this example:
> CREATE OR REPLACE FUNCTION self_modify(INTEGER) RETURNS INTEGER AS $$
>spi_exec_query('CREATE OR REPLACE FUNCTION self_modify(INTEGER) RETURNS
> INTEGER AS \'return $_[0] * 3;\' LANGUAGE plperl;');
>spi_exec_query('select self_modify(42) AS a');
>return $_[0] * 2;
> $$ LANGUAGE plperl;
> select self_modify(42);
> So I think we need to institute a reference counting scheme for
> the plperl_proc_desc records ...
The attached patch fixes the problem I'm seeing. I am not sure whether
it fixes what you saw; the crash you showed is in the right place, but
unless there was a recursive call to a pl/perl function, I don't see
how the existing code could have freed the prodesc too soon.
regards, tom lane
diff --git a/src/pl/plperl/expected/plperl.out b/src/pl/plperl/expected/plperl.out
index 906dc15e0ca097ec962c6dce9a08b29cb31d35b5..29c1d11c447e6087fee85565c0bf458cbc21486d 100644
*** a/src/pl/plperl/expected/plperl.out
--- b/src/pl/plperl/expected/plperl.out
*** $$ LANGUAGE plperl;
*** 693,695
--- 693,713
SELECT text_scalarref();
ERROR: PL/Perl function must return reference to hash or array
CONTEXT: PL/Perl function "text_scalarref"
+ -- check safe behavior when a function body is replaced during execution
+ CREATE OR REPLACE FUNCTION self_modify(INTEGER) RETURNS INTEGER AS $$
+spi_exec_query('CREATE OR REPLACE FUNCTION self_modify(INTEGER) RETURNS INTEGER AS \'return $_[0] * 3;\' LANGUAGE plperl;');
+spi_exec_query('select self_modify(42) AS a');
+return $_[0] * 2;
+ $$ LANGUAGE plperl;
+ SELECT self_modify(42);
+ self_modify
+ -
+ 84
+ (1 row)
+
+ SELECT self_modify(42);
+ self_modify
+ -
+ 126
+ (1 row)
+
diff --git a/src/pl/plperl/plperl.c b/src/pl/plperl/plperl.c
index bfa805d944f7b309428b6818b7160215c1b8e9fc..2c39edac5bd93ca8b446aafb88a17e0b7a5088db 100644
*** a/src/pl/plperl/plperl.c
--- b/src/pl/plperl/plperl.c
*** PG_MODULE_MAGIC;
*** 70,75
--- 70,76
*
* The plperl_interp_desc structs are kept in a Postgres hash table indexed
* by userid OID, with OID 0 used for the single untrusted interpreter.
+ * Once created, an interpreter is kept for the life of the process.
*
* We start out by creating a "held" interpreter, which we initialize
* only as far as we can do without deciding if it will be trusted or
*** typedef struct plperl_interp_desc
*** 95,122
/**
* The information we cache about loaded procedures
**/
typedef struct plperl_proc_desc
{
char *proname; /* user name of procedure */
! TransactionId fn_xmin;
ItemPointerData fn_tid;
plperl_interp_desc *interp; /* interpreter it's created in */
! bool fn_readonly;
! bool lanpltrusted;
bool fn_retistuple; /* true, if function returns tuple */
bool fn_retisset; /* true, if function returns set */
bool fn_retisarray; /* true if function returns array */
Oid result_oid; /* Oid of result type */
FmgrInfo result_in_func; /* I/O function and arg for result type */
Oid result_typioparam;
int nargs;
FmgrInfo arg_out_func[FUNC_MAX_ARGS];
bool arg_is_rowtype[FUNC_MAX_ARGS];
Oid arg_arraytype[FUNC_MAX_ARGS]; /* InvalidOid if not an array */
- SV *reference;
} plperl_proc_desc;
/**
* For speedy lookup, we maintain a hash table mapping from
* function OID + trigger flag + user OID to plperl_proc_desc pointers.
--- 96,139
/**
* The information we cache about loaded procedures
+ *
+ * The refcount field counts the struct's reference from the hash table shown
+ * below, plus one reference for each function call level that is using the
+ * struct. We can release the struct, and the associated Perl sub, when the
+ * refcount goes to zero.
**/
typedef struct plperl_proc_desc
{
char *proname; /* user name of procedure */
! TransactionId fn_xmin; /* xmin/TID of procedure's pg_proc tuple */
ItemPointerData fn_tid;
+ int refcount; /* reference count of this struct */
+ SV *reference; /* CODE reference for Perl sub */
plperl_interp_desc *interp; /* interpreter it's created in */
! bool fn_readonly; /* is function readonly (not volatile)? */
! bool lanpltrusted; /* is it plperl, rather than plperlu? */
bool fn_retistuple; /* true, if function returns tuple */
bool fn_retisset; /* true, if function returns set */
bool fn_retisarray; /* true if function returns array */
+ /* Conversion info for function's result type: */
Re: [BUGS] BUG #7524: Partitioning
On 09/09/12 14:01, Kevin Grittner wrote: wrote: The TWO most important factors in hindering us to convert to Postgres are the following: Parallel execution of queries. No Table Partitioning Not a bug, so off-topic for this list. If you need help figuring out how best to use PostgreSQL, or whether it is a good fit for your use-case, a post to pgsql-nov...@postgresql.org would be more appropriate. Or even -hackers - but it would make sense to ask 2 questions along the lines of: 1/ What is the current state of table partitioning...is anyone working on something a bit more native than abusing inheritance? 2/ Is anyone working on parallel query execution? Regards Mark -- 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 #7524: Partitioning
On 09/09/12 6:04 PM, Mark Kirkwood wrote: 1/ What is the current state of table partitioning...is anyone working on something a bit more native than abusing inheritance? enterpriseDB's commercial 'oracle compatible' fork has the Oracle DDL for creating and managing partitions, but afaik, it uses the same internal inheritance mechanisms. 2/ Is anyone working on parallel query execution? someone presented a FOSS project on the pg-general list the other day that implements parallel execution using a postgres based engine, but it only supports fairly simple queries. I can't say I remember what it was called. -- john r pierceN 37, W 122 santa cruz ca mid-left coast -- 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 #7524: Partitioning
On 09/09/12 9:31 PM, John R Pierce wrote: 2/ Is anyone working on parallel query execution? someone presented a FOSS project on the pg-general list the other day that implements parallel execution using a postgres based engine, but it only supports fairly simple queries. I can't say I remember what it was called. ah, was this https://launchpad.net/stado -- john r pierceN 37, W 122 santa cruz ca mid-left coast -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
