Messages posted by: shoaib1

You will first need to delete a file named 'vpd.properties' under the user home folder. Once that is done you can run the installer again.

Let us know in case you have any further question with this.

In the past I have seen such problems with systems where the queries are not properly tuned and the indexes not been properly made and that ends up in not choosing the proper scans on tables which results in bad execution time and that actually takes all the processing power and memory usage.

First thing I will like to see while debugging such would be the following:

- Value for kernel.shmmax (OS level)
- Values for edb_dynatune (postgresq.conf file setting)
- Value for the query 'show shared_buffers'
- Type of queries that are getting executed normally on the database server.

Once you provide us with this information, we can then move on to the next step in order to diagnose the root cause.

Best Regards,

In our current release that is not possible but our next release that is expected in a few weeks time supports this feature with a GUC session level variable.

Stay tuned for the new release... We will update on the forum accordingly.

Thanks,

No problem David, please do let me know in case you need further help with this.

Regards,

Hi David,

I am afraid that doing the backup without using the above mentioned mechanism can not help in the PITR process as the file identified by pg_stop_backup's result is the last segment that needs to be archived to complete the backup. The backup history file 'label' (as mentioned above) is just a small text file. It contains the label string you gave to pg_start_backup, as well as the starting and ending times and WAL segments of the backup. If you used the label to identify where the associated dump file is kept, then the archived history file is enough to tell you which dump file to restore, should you need to do so.

Regards,

Try setting the environment variable LD_LIBRARY_PATH with the path to libpq.so.5 for the user with which you are trying to launch isql.

Its a *very known problem* with retrieving large amounts of data where the client machine or server doesn't have enough memory to handle the data.

If you are getting the data through a connector like JDBC use setFetchSize() variable for that JDBC connection which creates an implicit cursor and fetches only the amount of data which is passed by setFetchSize.

Like the following:

Statement stmt = conn.createStatement();
conn.setAutoCommit(false);
stmt.setFetchSize(100);
ResultSet rs = stmt.executeQuery("select * from table_name");
rs.setFetchDirection(ResultSet.FETCH_FORWARD);
while (rs.next())
System.out.println(rs.getString(1));

In case you are doing through EDB-PSQL then try using a cursor based approach and at once only fetch the data that your box can handle OR you can also use the LIMIT and OFFSET combination with ORDER BY clause to get the big amount in small chunks.

Thanks,

>>If I try to execute the same script from another machine or >>from the server I get the message "current transaction is >>aborted, commands ignored until end of transaction block"

This means there is some error in your script that is making the whole transaction block to abort and rollback. Please review your script and look for any errors in there.

Other then that the reindex process looks all normal and has been completed successfully.

I am not sure if that will help you but we are introducing the statement level rollbacks in our next major release where such a failure in a transaction will not rollback the whole transaction but will do that for just the specific statement which failed.

Hi Cristian,

Can you show us an example with code snippet of what you were trying to achieve? as that might help us to provide a workaround for now.

Just adding to what Farhan mentioned, we are expecting the statement level rollbacks in our next major release. That will be helpful with the statement failures inside a transactional block and will not rollback the whole transaction for a single statement failure.

pg_dump is used to get a backup of a specific database while pg_dumpall can be used to take a data cluster wide backup of all databases.

Try using the following for Developer Studio:

select text(cast('2006-01-01' as timestamp) - cast('2007-01-01' as timestamp))

Regards,

You can display it in three lines like this:

select 'This\nBest\nWay' from dual;

Thanks,

Hi Chris,

Please find answers to your questions below:

>>is it possible to create check constraints like:
>>If field1=value1 then field2 must equal value2?

I think this is something you want to do:

if field = value1 AND field2 = value2
then
<code comes in here>
else
<code comes in here>

>>One more question: is it possible to return custom error >>messages in case data do not match constraints?

You can handle that using exceptions from the SQL code.

Thank you,

You have been our very frequent poster and an old friend of EnterpriseDB

.

I appreciate sharing your solution with other users.

We have a lot of new features coming up in our next major release (based on PostgreSQL 8.2) that is expected to be there in a few weeks time. Stay tuned....

Best Regards,

By simply issuing the Linux command "unset NLS_LANG" might help you resolve this problem...

Thank you,

That is not allowed with the current version of snapshot replication.

Thank you

Yes, you can have indexes stored in a specific tablespace. You can find detailed help for CREATE INDEX at http://www.enterprisedb.com/documentation/sql-createindex.html

Thank you,

Hi Mike,

Currently we do not support using refcursor as OUT parameter in a procedure but that sure is part of our next major release.

Stay tuned...

Thank you,

Hi Raghu,

Which registries you deleted manually? as this should all be done automatically with the un-installer that comes with EnterpriseDB installation and we will never recommend our user to do this manually but will prefer to doing with the un-installer.

In order to debug the problem further I will like you to do the following:

- Go to C:\Documents and Settings\<yourUser>\.enterprisedb\devstudio and delete all build folders from there so that the folder 'devstudio' is empty now

- Open command line

- Browse to <EnterpriseDB-Install-Folder>\8.1\devstudio

- Now execute

..\jre1.5\bin\java -Xmx256M -Duser.language=en -jar edb-devstudio.jar

And let me the output in this case....

Thank you,

Just testing out different variations found out that "varchar2" doesn't work good with the create table wizard.

I have forwarded this to the concerned department and hopefully we will get this fixed for our upcoming release.

Regards,

We can help you out with tips on improving performance on I/O, go for a multi disk setup. This makes an enormous difference on transaction-processing systems, and a significant improvement on any application where the entire database does not fit in RAM. Once you have a multi disk setup you can put the database transaction logs (pg_xlog) on its own, dedicated disk resource (an array or plain disk), that makes a lot of difference in performance on databases with high write activity.

Adding to it, we also provide "At request production tuning" service, please contact sales@enterprisedb.com for further details on that.

Thank you,

We will like to see the Java code being used and the DDL for tables involved as that will help us replicating the problem at our end and giving a solution to this.

Thank you,

Hi Sergey,

Using 'quote_literal' string function along with EXECUTE statement might help you with the SQL injection problem. You can find more details and examples at http://www.postgresql.org/docs/8.1/static/plpgsql-statements.html under "36.6.5. Executing Dynamic Commands"

Thank you,